[VB/.Net] DateTime perikelen

[RobIII]

Modbreak:

Let op: deze topic is afgesplitst uit [rml][ alg] slechtste prog voorbeelden.[/rml]

Maasluip schreef op maandag 15 augustus 2005 @ 14:59:
Zo te zien is dit VB, daar wordt datum/tijd als een double gezien met de datum in het integer deel. Wat let je om dNextDay = dNextDay + 1 te doen?

VB kent gewoon een Date datatype (hoewel dat onderhuids natuurlijk anders is). Je zou, als alternatief, ook met DateSerial kunnen werken, hoewel DateAdd wel een aardige is in dit geval.

LuCarD schreef op maandag 15 augustus 2005 @ 15:00:
Geschreven door een collega uit India:

Dude, die is wel een vermelding op thedailywtf.com waard

[ Voor 32% gewijzigd door .oisyn op 16-08-2005 16:40 ]

[Maasluip]

RobIII schreef op maandag 15 augustus 2005 @ 15:01:
[...]

VB kent gewoon een Date datatype (hoewel dat onderhuids natuurlijk anders is). Je zou, als alternatief, ook met DateSerial kunnen werken, hoewel DateAdd wel een aardige is in dit geval.

Ja, goed, je noemt het Date en dat betekent dat je in je output ook een hele mooie datum krijgt te zien, maar onderhuids is het gewoon een double.
Doe maar eens

Visual Basic .NET:

Sub test()

    Dim dDatum As Date
    
    dDatum = Now()
    
    Debug.Print dDatum
    Debug.Print dDatum + (1 / 24)
    Debug.Print dDatum + 1

End Sub

En dat gaat ook goed bij maand- of jaar-eindes. DateAdd zou ik alleen gebruiken als je een week, een maand of een jaar (o.i.d.) bij een datum wil optellen. Uiteraard werkt het ook voor een dag, maar dat is een beetje overkill. IMHO.
(zegt-ie met droge ogen terwijl hij wel [rml]Maasluip in "[ alg] slechtste prog voorbeelden."[/rml] programmeert)

[ Voor 12% gewijzigd door Maasluip op 15-08-2005 15:12 ]

[NMe]

Maasluip schreef op maandag 15 augustus 2005 @ 15:09:
En dat gaat ook goed bij maand- of jaar-eindes. DateAdd zou ik alleen gebruiken als je een week, een maand of een jaar (o.i.d.) bij een datum wil optellen. Uiteraard werkt het ook voor een dag, maar dat is een beetje overkill. IMHO.

Ik vind DateAdd gebruiken toch echt wel een stuk duidelijker dan zomaar 1 erbij optellen voor een dag of 1/24 voor een uur. Die functie is er niet voor niks, en op zo'n niveau gaan optimaliseren alleen omdat je het aanroepen van de functie "overkill" vindt, vind ik een beetje je doel voorbij streven. Je code moet wel leesbaar blijven.

[Janoz]

Maasluip schreef op maandag 15 augustus 2005 @ 15:09:
En dat gaat ook goed bij maand- of jaar-eindes.

En toen werdt het wintertijd...

Is een uur dan 1/25 of een dag 25/24

[Maasluip]

Janoz schreef op maandag 15 augustus 2005 @ 15:50:
[...]


En toen werdt het wintertijd...

Is een uur dan 1/25 of een dag 25/24

Nee, een uur blijft gewoon 1/24 en een dag blijft gewoon 24/24. Wat de reactie van windows is als je als uitkomst een niet bestaande tijd krijgt (omschakeling naar zomertijd en dan een tijd tussen 2:00 en 3:00) weet ik niet, maar DateAdd geeft je die tijd net ze makkelijk als mijn methode. Ook met de omschakeling naar de wintertijd telt DateAdd heel gewoon alle uren door.

Hoe los jij het op met zomertijd/wintertijd en hoe zorg je ervoor dat je geen niet-bestaande tijd krijgt?

[Janoz]

Dat is dus gewoon niet waar. Als het zondag 00:05 is en je telt hier 24 uur bij op, kom je uit op zondag 23:05 ipv maandag 0:05 omdat die dag uit 25 uur bestaat. Gebruik je dateAdd, dan kun je er ten alle tijden vanuit gaan dat er exact dat aantal bij opgetelt wordt dat je ook verwacht. Ik snap niet dat sommige mensen, omdat ze het zelf maar overkill vinden, dit soort bugs in hun code stoppen.

[Woy]

De tijd tussen 2:00 en 3:00 is voor windows volgens mij gewoon valide. Alleen zit er een controle op dat hij de tijd dan gewoon een uur verzet. Dus als de tijd een uur vooruit gezet wordt en je zet de tijd op 2:21 en windows ziet dat hij nog niet aangepast heeft voor wintertijd dan zet hij hem ( eventueel na vraag of dat moet gebeuren ) naar 3:21. ik denk zelfs als je dan de klok weer een half uur terug zet naar 2:51 dat windows dat niet meer aanpast ( niet getest overigens ).

[edit]

Dat is dus gewoon niet waar. Als het zondag 00:05 is en je telt hier 24 uur bij op, kom je uit op zondag 23:05 ipv maandag 0:05 omdat die dag uit 25 uur bestaat. Gebruik je dateAdd, dan kun je er ten alle tijden vanuit gaan dat er exact dat aantal bij opgetelt wordt dat je ook verwacht. Ik snap niet dat sommige mensen, omdat ze het zelf maar overkill vinden, dit soort bugs in hun code stoppen.

blijkbaar had ik het dan fout. Maar je hebt ieder geval gewoon gelijk dat je beter de DateAdd functie kan gebruiken omdat het gewoonweg al beter leesbaar is. Al zou er in de dateadd functie nog gewoon staan

code:

if hour
   date += hours

Kan niet geloven dat dat zoveel overhead geeft dat je programma niet meer werkbaar is. Als dat zo is dan zit je volgens mij zowiezo al verkeerd bij vb

[ Voor 47% gewijzigd door Woy op 16-08-2005 09:09 ]

[Maasluip]

Janoz schreef op dinsdag 16 augustus 2005 @ 09:03:
Dat is dus gewoon niet waar. Als het zondag 00:05 is en je telt hier 24 uur bij op, kom je uit op zondag 23:05 ipv maandag 0:05 omdat die dag uit 25 uur bestaat. Gebruik je dateAdd, dan kun je er ten alle tijden vanuit gaan dat er exact dat aantal bij opgetelt wordt dat je ook verwacht. Ik snap niet dat sommige mensen, omdat ze het zelf maar overkill vinden, dit soort bugs in hun code stoppen.

Ik krijg geen verschil tussen DateAdd en + hoor.
Als ik me niet vergis ging de zomertijd in op 27 maart en gaat de wintertijd in op 30 oktober.

Visual Basic:

Sub test()

    Dim dDatum As Date
    
    dDatum = CDate("26-03-2005") + 1 / 48
    Debug.Print dDatum
    dDatum = DateAdd("h", 24, dDatum)
    Debug.Print dDatum
    dDatum = DateAdd("h", 24, dDatum)
    Debug.Print dDatum
    
    dDatum = CDate("29-10-2005") + 1 / 48
    Debug.Print dDatum
    dDatum = DateAdd("h", 24, dDatum)
    Debug.Print dDatum
    dDatum = DateAdd("h", 24, dDatum)
    Debug.Print dDatum
    
End Sub

levert bij mij als output

code:

26-03-2005 0:30:00 
27-03-2005 0:30:00 
28-03-2005 0:30:00
29-10-2005 0:30:00 
30-10-2005 0:30:00 
31-10-2005 0:30:00

Ook al zijn er maar 23 uur tussen 27-03-2005 0:30 en 28-03-2005 0:30 en 25 uur tussen 30-10-2005 0:30:00 31-10-2005 0:30:00.

[.oisyn]

Maasluip schreef op dinsdag 16 augustus 2005 @ 09:58:
Ik krijg geen verschil tussen DateAdd en + hoor.
Als ik me niet vergis ging de zomertijd in op 27 maart en gaat de wintertijd in op 30 oktober.

Waar test je de + dan? Ik zie alleen een DateAdd implementatie.

[ Voor 52% gewijzigd door .oisyn op 16-08-2005 10:51 ]

[.oisyn]

rwb schreef op dinsdag 16 augustus 2005 @ 09:06:
De tijd tussen 2:00 en 3:00 is voor windows volgens mij gewoon valide. Alleen zit er een controle op dat hij de tijd dan gewoon een uur verzet. Dus als de tijd een uur vooruit gezet wordt en je zet de tijd op 2:21 en windows ziet dat hij nog niet aangepast heeft voor wintertijd dan zet hij hem ( eventueel na vraag of dat moet gebeuren ) naar 3:21.

Computers gebruiken meestal niet zo'n feitelijke klok als wij mensen, maar doen ze alles in 1 tijdsysteem (GMT over het algemeen). Pas bij het omzetten naar een textuele representatie wordt de huidige locale erbij gepakt en wordt die tijd geconverteerd, waardoor het dus mogelijk is dat 2 verschillende tijdstippen naar dezelfde tijd mappen, of dat er ineens een gat van een uur tussen lijkt te zitten. In werkelijkheid is dat niet zo, en ook windows past "de klok" niet aan (hooguit de bios clock die niet zo werkt geloof ik).

Dat zou ook wat zijn, dat zou betekenen dat files na het terugzetten van de klok ineens ouder zijn dan de files die er al staan, wat bij veel compilatieprocessen betekent dat er niet meer gecompileerd hoeft te worden omdat de geupdate sourcefiles immers ouder zijn dan de al geproduceerde binaries

[RobIII]

Visual Basic:

    Dim dtStartDA As Date
    Dim dtStartPL As Date
    Dim dtEnd As Date
    
    dtStartDA = DateSerial(2005, 1, 1)
    dtStartPL = dtStartDA
    dtEnd = DateSerial(2006, 1, 1)
    
    While dtStartDA < dtEnd
        dtStartDA = DateAdd("h", 1, dtStartDA)
        dtStartPL = dtStartPL + 1 / 24
        If dtStartDA <> dtStartPL Then Debug.Print dtStartDA, dtStartPL
    Wend

No output, hence de Plus en DateAdd leveren hetzelfde resultaat op. Maar dan nog vind ik het in dit soort situaties zinloze optimalisaties en zou ik 100% voor de DateAdd gaan (daar is die functie immers voor).

Wel is de "plus" methode aanzienlijk sneller:

Visual Basic:

    Dim dtStartDA As Date
    Dim dtStartPL As Date
    Dim dtEnd As Date
    Dim tStart As Single
    
    dtStartDA = DateSerial(2000, 1, 1)
    dtStartPL = dtStartDA
    dtEnd = DateSerial(2050, 1, 1)
    
    tStart = Timer
    While dtStartDA < dtEnd
        dtStartDA = DateAdd("h", 1, dtStartDA)
    Wend
    Debug.Print "DateAdd method: " & FormatNumber(Timer - tStart, 5)

    tStart = Timer
    While dtStartPL < dtEnd
        dtStartPL = dtStartPL + 1 / 24
    Wend
    Debug.Print "Plus method:    " & FormatNumber(Timer - tStart, 5)

Output:

code:

DateAdd method: 2,62500
Plus method:    0,09375

Vervang je dan 1/24 nog door "4.16666666666667E-02" dan ben je zelfs nog een tikkie sneller.

[ Voor 71% gewijzigd door RobIII op 16-08-2005 11:10 ]

[Woy]

.oisyn schreef op dinsdag 16 augustus 2005 @ 10:57:
[...]


Computers gebruiken meestal niet zo'n feitelijke klok als wij mensen, maar doen ze alles in 1 tijdsysteem (GMT over het algemeen). Pas bij het omzetten naar een textuele representatie wordt de huidige locale erbij gepakt en wordt die tijd geconverteerd, waardoor het dus mogelijk is dat 2 verschillende tijdstippen naar dezelfde tijd mappen, of dat er ineens een gat van een uur tussen lijkt te zitten. In werkelijkheid is dat niet zo, en ook windows past "de klok" niet aan (hooguit de bios clock die niet zo werkt geloof ik).

Dat zou ook wat zijn, dat zou betekenen dat files na het terugzetten van de klok ineens ouder zijn dan de files die er al staan, wat bij veel compilatieprocessen betekent dat er niet meer gecompileerd hoeft te worden omdat de geupdate sourcefiles immers ouder zijn dan de al geproduceerde binaries

hehe ja daar heb je gelijk in. Mijn aaname was meer gebaseerd op het feit dat windows vroeger altijd vroeg of je wou aanpassen aan winter/zomertijd en ik nam daardoor altijd aan dat windows de klok gewoon een uurtje verzette.

[Wolfboy]

.oisyn schreef op dinsdag 16 augustus 2005 @ 10:57:
....en ook windows past "de klok" niet aan (hooguit de bios clock die niet zo werkt geloof ik).

Dat doet windows volgens mij wel, ik heb namelijk al vaak genoeg meegemaakt dat windows de bios klok veranderd naar de tijd in je huidige tijdzone met zomer/wintertijd erbij.
Als ik namelijk naar een linux/unix installatie boot (die dus verwachten dat je bios klok op GMT staat) zie je opeens dat de tijd niet meer klopt.

[Maasluip]

.oisyn schreef op dinsdag 16 augustus 2005 @ 10:50:
[...]


Waar test je de + dan? Ik zie alleen een DateAdd implementatie.

De output van + heb ik niet gepost omdat iedereen wel op z'n klompen kan aanvullen dat iets + 1 altijd iets + 1 is en niet iets + 1 min een beetje. Geloof me, er zit geen verschil in. DateAdd is net zo zomertijd-aware als +. Niet aware dus.
Het is een kwestie van wat je prettiger vindt. Persoonlijk vind ik Datum + 1 sneller te lezen dat DateAdd("d", 1, Datum). Maar goed, dat is persoonlijk.

[RobIII]

Maasluip schreef op dinsdag 16 augustus 2005 @ 11:25:
[...]
Het is een kwestie van wat je prettiger vindt. Persoonlijk vind ik Datum + 1 sneller te lezen dat DateAdd("d", 1, Datum). Maar goed, dat is persoonlijk.

Het is dus wel zo dat die "+ 1" in de huidige implementatie "+ 1 dag" betekent, maar een service pack of hotfix zou dit teniet kunnen doen in theorie *(natuurlijk is die kans miniem, zeker nu VB6 eigenlijk obsolete is). Als je dat soort problemen wil voorkomen programmeer je gewoon netjes en gebruik je dus DateAdd (die bij een nieuwe implementatie dan nog steeds zou (moeten) doen wat 't zegt te doen).
Nu is het voor VB6 misschien wel erg lame om zo uit te leggen, maar denk eens aan de vele verschillende implementaties van C(++) e.d. waarbij code bij de ene compiler andere dingen doet dan bij een andere compiler. Dit soort zaken wil je gewoon voor zijn. Simpel.

[ Voor 3% gewijzigd door RobIII op 16-08-2005 11:29 ]

[.oisyn]

Wolfboy schreef op dinsdag 16 augustus 2005 @ 11:04:
[...]
Dat doet windows volgens mij wel, ik heb namelijk al vaak genoeg meegemaakt dat windows de bios klok veranderd naar de tijd in je huidige tijdzone met zomer/wintertijd erbij.
Als ik namelijk naar een linux/unix installatie boot (die dus verwachten dat je bios klok op GMT staat) zie je opeens dat de tijd niet meer klopt.

Dat zeg ik toch? Staat tussen de haakjes.

Maasluip schreef op dinsdag 16 augustus 2005 @ 11:25:
[...]
De output van + heb ik niet gepost omdat iedereen wel op z'n klompen kan aanvullen dat iets + 1 altijd iets + 1 is en niet iets + 1 min een beetje. Geloof me, er zit geen verschil in.

Ik geloof je niet zolang je dat niet test, en dat was nou juist de cullprit hier in deze draad. Of DateAdd hetzelfde was als iets erbij optellen. Het punt is dat je met DateAdd zelf kunt kiezen hoeveel tijdsenheden je erbij op wilt tellen, met de + operator lijkt dat een aantal dagen te zijn als reëel getal. Maar is een dag dan altijd 24 uur of hangt dat af van de tijdszone? Als een dag altijd 24 uur is kun je met +1 dus op een andere tijd uitkomen, terwijl als het afhankelijk is van de tijdzone je er niet vanuit kunt gaan dat 1/24 altijd een uur is. Zie je nu het punt dat Janoz probeerde te maken?

RobIII schreef op dinsdag 16 augustus 2005 @ 11:39:
Dit is nou mijn nachtmerrie. Code van anderen, waarop je op de eerste 15 keer dat je het leest niet ziet waar de fout zit. En als je vervolgens aan het debuggen slaat jezelf voor je kop slaat en roept: "Dat ik dat niet heb gezien!".

Die zijn idd erg irritant, hoewel ik moet zeggen dat ik de fout bij deze direct zag. Code moet je dan ook niet lezen als taal, en het helpt om de operator precedence uit je hoofd te kennen. Zelf heb vind ik dingen als misplaatste accolades of vage C/C++ macro's die niet helemaal doen wat je denkt dat ze doen het ergst. Zo snapte ik deze compilerfout gewoonweg niet:

C++:

MyType bla = static_cast<MyType>(woei);

en de foutmelding:

error C2947: expecting '>' to terminate template-argument-list, found '>>'

Dan denk je "er staat toch geen >> ", om er vervolgens achter te komen dat MyType een #define is voor Foo<Bar> ipv een typedef

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 12:34:
[nohtml]
Ik geloof je niet zolang je dat niet test, en dat was nou juist de cullprit hier in deze draad. Of DateAdd hetzelfde was als iets erbij optellen.

[rml]RobIII in "[ alg] slechtste prog voorbeelden."[/rml]
Dat heb ik maar voor 'm gedaan

.oisyn schreef op dinsdag 16 augustus 2005 @ 12:34:
Die zijn idd erg irritant, hoewel ik moet zeggen dat ik de fout bij deze direct zag.

Ik ook wel, maar dat is omdat 'ie in dit topic staat en je dus bij voorbaat al een WTF aan 't zoeken bent en ook nog eens omdat 't maar alleen de relevante code is. Als er een lap code omheen staat lees je er al sneller over heen.

[ Voor 32% gewijzigd door RobIII op 16-08-2005 12:41 ]

[.oisyn]

RobIII schreef op dinsdag 16 augustus 2005 @ 12:40:
[...]

[rml]RobIII in "[ alg] slechtste prog voorbeelden."[/rml]
Dat heb ik maar voor 'm gedaan

Right, die heb ik even gemist. Blijkbaar werkt de + dus altijd met stappen van 24 uur. Ergo, bij tijdshoeveelheden is het gelijk. Maar dat betekent dat het bij dagen niet gelijk kan zijn. Een date+1 zet óf de dag 1 verder, of telt er 24 uur bij op. Hier lijkt hij er 24 uur bij op te tellen, dus een DateAdd("d", 1) is wat anders dan date + 1 (bij de eerste doet hij een dag, bij de tweede 24 uur).

Kun je je test nog eens doen met het optellen van dagen ipv uren?

[Maasluip]

.oisyn schreef op dinsdag 16 augustus 2005 @ 12:34:

Ik geloof je niet zolang je dat niet test,

Ik heb het getest. Denk je dat ik zulke statements geef zonder zeker te weten waar ik sta? De output met + is echt hetzelfde als met DateAdd. Het zou heel mooi geweest zijn als DateAdd zomertijd-aware was, maar dat is het niet. Ook als je steeds een uur erbij optelt telt DateAdd gewoon alle uren door.

en dat was nou juist de cullprit hier in deze draad. Of DateAdd hetzelfde was als iets erbij optellen. Het punt is dat je met DateAdd zelf kunt kiezen hoeveel tijdsenheden je erbij op wilt tellen, met de + operator lijkt dat een aantal dagen te zijn als reëel getal. Maar is een dag dan altijd 24 uur of hangt dat af van de tijdszone? Als een dag altijd 24 uur is kun je met +1 dus op een andere tijd uitkomen, terwijl als het afhankelijk is van de tijdzone je er niet vanuit kunt gaan dat 1/24 altijd een uur is. Zie je nu het punt dat Janoz probeerde te maken?

Zelfs als je een tijdzone bedenkt waar je geen 24 uren in een dag hebt is +1 nog altijd een dag. Alleen omdat het aantal uren anders is doet + 1/24 niet een uur erbij tellen maar iets anders.
Sterker nog, als je een tijdzone met 10 uur in een dag hebt en je gebruikt DateAdd("h", 1..., juist dan krijg je niet wat je verwacht, want je telt er opeens 2,4 keer meer bij op dan in de andere tijdzone.

Maar goed, dat is in mijn ogen allemaal puur hypothetisch, er zijn geen tijdzones met iets anders dan 24 uur in een dag, het basisformaat van een date type wordt niet aangepast en als je daar wel van uit moet gaan kun je er ook niet van uitgaan dat DateAdd("d"... altijd dezelfde functionaliteit blijft houden. Of +, als het daar om gaat.

DateAdd heeft zeker nut, als je bijvoorbeeld een maand erbij op wil tellen (dat is 28, 29, 30 of 31 dagen) of een jaar (356 of 366 dagen). Maar voor mij heeft DateAdd("d", 1... geen nut boven + 1. En daar ging het uiteindelijk om.
En wat mij betreft kunnen deze discussie sluiten, het is duidelijk dat we verschillende blikpunten hebben en dat we niet nader tot elkaar komen in deze

[Janoz]

het basisformaat van een date type wordt niet aangepast en als je daar wel van uit moet gaan kun je er ook niet van uitgaan dat DateAdd("d"... altijd dezelfde functionaliteit blijft houden.

Deze oorzaak gevolg stelling klopt niet helemaal. DateAdd("d" zal altijd zo blijven werken omdat dit zo vastgelegd is. Hoe het date type intern gerepresenteerd wordt is dat niet. Als de interne representatie verander wordt de DateAdd functie mee aangepast zodat hij dezelfde functionaliteit kunt behouden. De +1 veranderd niet mee.

[drm]

frickY:
Toen ik mijn collega vroeg waarom hij het niet zo deed;

PHP:

$bestelling = ereg_replace("[-]*","-", $bestelling);

als hij perse een regExp wou gebruiken

Ik kan wel een reden verzinnen

PHP:

$bestelling = "Dit is een bestelling zonder streepjes";
echo ereg_replace("[-]*","-", $bestelling);

-D-i-t- -i-s- -e-e-n- -b-e-s-t-e-l-l-i-n-g- -z-o-n-d-e-r- -s-t-r-e-e-p-j-e-s-

* drm zet $ 50 in op frickY's collega

[RobIII]

Janoz schreef op dinsdag 16 augustus 2005 @ 13:55:
[...]

Deze oorzaak gevolg stelling klopt niet helemaal. DateAdd("d" zal altijd zo blijven werken omdat dit zo vastgelegd is. Hoe het date type intern gerepresenteerd wordt is dat niet. Als de interne representatie verander wordt de DateAdd functie mee aangepast zodat hij dezelfde functionaliteit kunt behouden. De +1 veranderd niet mee.

Dat was ook mijn punt. Echter, hier wil ik wel aan toevoegen dan als de interne representatie aangepast zou worden (en dus de DateAdd daarbij ook) dan is er een kans dat de "+ 1" ook aangepast zal worden door de operator "+" bij het gebruik i.c.m. een date te overloaden ("onderwater" dus niet +1 maar +xxx). Ik zou er alleen never nooit op vertrouwen.
Gelukkig kunnen we nu redelijk zeker vaststellen dat het in het geval van VB6 waarschijnlijk nooit meer veranderd zal worden

[ Voor 7% gewijzigd door RobIII op 16-08-2005 14:18 ]

[.oisyn]

Maasluip schreef op dinsdag 16 augustus 2005 @ 13:45:
[...]
Ik heb het getest. Denk je dat ik zulke statements geef zonder zeker te weten waar ik sta?

Lees de test van RobIII dan nog eens door, en mijn laatste post over dit onderwerp: .oisyn in "[alg] slechtste prog voorbeelden.". Jullie posts spreken elkaar tegen, dus of iemand test verkeerd, of iemand spreekt gewoon niet de waarheid . Jij zegt dat +1 hetzelfde is als een dag erbij tellen, RobIII zegt dat +1/24 hetzelfde is als een uur erbij tellen. Ik zeg dat het niet allebei kan, zoals ik in mijn vorige post aantoonde. Dus óf je rekent met dagen, óf met vaste tijdseenheden, allebei kan simpelweg gewoon niet.

RobIII heeft aangetoond dat het met vaste tijdseenheden werkt. Het enige wat ik me hier nog bij voor kan stellen is dat RobIII niet aan zomertijd doet (dat is een tijdzone instelling) waardoor de test niet faalt. Either way werk je dus gewoon beter met DateAdd, omdat de + in het ene geval (als jij gelijk hebt) niet goed gedefinieerd met units kleiner dan een dag kan werken, en in het andere geval (als RobIII gelijk heeft) niet met dagen. Ik gok, gezien de aard van het Date type, dat jij gelijk hebt en dat RobIII de zomertijd instelling miste tijdens het testen, maar zeker weten doe ik het pas als iemand even de test van RobIII uitbreidt met dagen, en die test runt op een systeem dat aan zomertijd doet en daarvan het resultaat hier post

[ Voor 22% gewijzigd door .oisyn op 16-08-2005 14:22 ]

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 14:18:
RobIII heeft aangetoond dat het met vaste tijdseenheden werkt. Het enige wat ik me hier nog bij voor kan stellen is dat RobIII niet aan zomertijd doet (dat is een tijdzone instelling) waardoor de test niet faalt.

* RobIII doet wel degelijk aan zomertijd
Ik heb het ook even (op verzoek) getest met dagen:

Visual Basic:

    Dim dtStartDA As Date
    Dim dtStartPL As Date
    Dim dtEnd As Date
     
    dtStartDA = DateSerial(2005, 1, 1)
    dtStartPL = dtStartDA
    dtEnd = DateSerial(2006, 1, 1)
     
    While dtStartDA < dtEnd
        dtStartDA = DateAdd("d", 1, dtStartDA)
        dtStartPL = dtStartPL + 1
        If dtStartDA <> dtStartPL Then Debug.Print dtStartDA, dtStartPL
    Wend

Wederom, geen output.

Maar lees ik nou scheef of zeggen we nou juist hetzelfde? Ik ben de kluts even kwijt

[ Voor 57% gewijzigd door RobIII op 16-08-2005 14:25 ]

[.oisyn]

RobIII, output dan eens rond de activatie van de zomertijd (27 maart 2005, om 2:00 gaat de klok een uur vooruit) de datums? Zowel bij het optellen van een dag als van een uur. Er moet iets niet kloppen

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 14:26:
RobIII, output dan eens rond de activatie van de zomertijd (27 maart 2005, om 2:00 gaat de klok een uur vooruit) de datums? Zowel bij het optellen van een dag als van een uur. Er moet iets niet kloppen

Uren optellen:

Visual Basic:

    Dim dtPL As Date
    Dim dtDA As Date
    Dim T As Long
    
    dtDA = DateSerial(2005, 3, 27) + TimeSerial(0, 0, 0)
    dtPL = dtDA
    For T = 0 To 5
        dtDA = DateAdd("h", 1, dtDA)
        dtPL = dtPL + 1 / 24
        Debug.Print dtDA, dtPL
    Next

Output:

code:

27-3-2005 1:00:00           27-3-2005 1:00:00 
27-3-2005 2:00:00           27-3-2005 2:00:00 
27-3-2005 3:00:00           27-3-2005 3:00:00 
27-3-2005 4:00:00           27-3-2005 4:00:00 
27-3-2005 5:00:00           27-3-2005 5:00:00 
27-3-2005 6:00:00           27-3-2005 6:00:00

Dagen optellen:

Visual Basic:

    Dim dtPL As Date
    Dim dtDA As Date
    Dim T As Long
    
    dtDA = DateSerial(2005, 3, 27) + TimeSerial(1, 0, 0)
    dtPL = dtDA
    For T = 0 To 1
        Debug.Print dtDA, dtPL
        dtDA = DateAdd("d", 1, dtDA)
        dtPL = dtPL + 1
    Next

Output:

code:

27-3-2005 1:00:00           27-3-2005 1:00:00 
28-3-2005 1:00:00           28-3-2005 1:00:00

Overigens houdt de DateDiff ook geen rekening met zomertijd:

Visual Basic:

    Dim dtStart As Date
    Dim dtEnd As Date
    
    dtStart = DateSerial(2005, 3, 27) + TimeSerial(1, 0, 0)
    dtEnd = DateSerial(2005, 3, 28) + TimeSerial(1, 0, 0)
    
    Debug.Print dtStart, dtEnd, "=>", DateDiff("h", dtStart, dtEnd)

En output:

code:

27-3-2005 1:00:00           28-3-2005 1:00:00           =>             24

Maar dat is natuurlijk ook een "interpretatie" probleem lijkt me. In "de werkelijkheid" moet je 1 uur verschil hebben (in dit geval ergens een uur missen) ergens, maar "op de klok" klopt dit natuurlijk nog gewoon.

[ Voor 53% gewijzigd door RobIII op 16-08-2005 14:40 ]

[.oisyn]

Daar klopt dus iets niet, 27-3-2005 2:00 bestaat niet, dat is 27-3-2005 3:00. Start eens bij 0:30, om zeker te zijn?

Maar goed, het hele Date type doet dus niet eens aan zomertijd blijkbaar, wat slecht zeg. Kun je ook uitrekenen met Date hoeveel tijd er tussen 2 datums zit (aftrekken dus)? Ik ben wel benieuwd hoeveel uur er tussen 27-3-2005 1:00 en 27-3-2005 4:00 zit. Hij zal wel 3 zeggen...

[ Voor 83% gewijzigd door .oisyn op 16-08-2005 14:34 ]

[Maasluip]

RobIII schreef op dinsdag 16 augustus 2005 @ 14:19:
[...]

Maar lees ik nou scheef of zeggen we nou juist hetzelfde? Ik ben de kluts even kwijt

Zoals je in je laatste post aantoont zeggen we hetzelfde. DateAdd is niet zomertijd-aware.

Visual Basic:

Sub test()
    
    Dim dDatumDA As Date
    Dim dDatumPL As Date

    dDatumDA = CDate("27-03-2005 0:30:00")
    dDatumPL = dDatumDA
    For i = 1 To 6
        Debug.Print dDatumDA; dDatumPL
        dDatumDA = DateAdd("h", 1, dDatumDA)
        dDatumPL = dDatumPL + 1 / 24
    Next i
    
End Sub

code:

27-03-2005 0:30:00 27-03-2005 0:30:00 
27-03-2005 1:30:00 27-03-2005 1:30:00 
27-03-2005 2:30:00 27-03-2005 2:30:00 
27-03-2005 3:30:00 27-03-2005 3:30:00 
27-03-2005 4:30:00 27-03-2005 4:30:00 
27-03-2005 5:30:00 27-03-2005 5:30:00

of per 15 minuten:

Visual Basic:

Sub test()
    
    Dim dDatumDA As Date
    Dim dDatumPL As Date

    dDatumDA = CDate("27-03-2005 1:00:00")
    dDatumPL = dDatumDA
    For i = 1 To 10
        Debug.Print dDatumDA; dDatumPL
        dDatumDA = DateAdd("n", 15, dDatumDA)
        dDatumPL = dDatumPL + 1 / 96
    Next i
    
End Sub

code:

27-03-2005 1:00:00 27-03-2005 1:00:00 
27-03-2005 1:15:00 27-03-2005 1:15:00 
27-03-2005 1:30:00 27-03-2005 1:30:00 
27-03-2005 1:45:00 27-03-2005 1:45:00 
27-03-2005 2:00:00 27-03-2005 2:00:00 
27-03-2005 2:15:00 27-03-2005 2:15:00 
27-03-2005 2:30:00 27-03-2005 2:30:00 
27-03-2005 2:45:00 27-03-2005 2:45:00 
27-03-2005 3:00:00 27-03-2005 3:00:00 
27-03-2005 3:15:00 27-03-2005 3:15:00

[ Voor 84% gewijzigd door Maasluip op 16-08-2005 14:35 ]

[.oisyn]

Dat hele Date type is dus nog een grotere WTF?! dan de code die ermee gemoeid is . Hoe kun je hier nou reliable code mee schrijven

[Erkens]

.oisyn schreef op dinsdag 16 augustus 2005 @ 14:37:
Dat hele Date type is dus nog een grotere WTF?! dan de code die ermee gemoeid is . Hoe kun je hier nou reliable code mee schrijven

Opzich snap ik dat data type wel, want wat nu als je met een tijd wilt werken van bijvoorbeeld een server die in een andere tijdzone zit zonder die zomertijd? Maar ik ben het wel met je eens dat als je lokaal met een tijd moet werken dan moet je wel de mogelijkheid hebben om rekening te houden _met_ zomertijd.

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 14:32:
Daar klopt dus iets niet, 27-3-2005 2:00 bestaat niet, dat is 27-3-2005 3:00. Start eens bij 0:30, om zeker te zijn?

Maar goed, het hele Date type doet dus niet eens aan zomertijd blijkbaar, wat slecht zeg. Kun je ook uitrekenen met Date hoeveel tijd er tussen 2 datums zit (aftrekken dus)? Ik ben wel benieuwd hoeveel uur er tussen 27-3-2005 1:00 en 27-3-2005 4:00 zit. Hij zal wel 3 zeggen...

U roept, wij draaien
Aftrekken van data:

Visual Basic:

    Dim dtStart As Date
    Dim dtEnd As Date
    
    dtStart = DateSerial(2005, 3, 27) + TimeSerial(1, 0, 0)
    dtEnd = DateSerial(2005, 3, 27) + TimeSerial(4, 0, 0)
    
    Debug.Print dtStart, dtEnd, "=>", DateDiff("h", dtStart, dtEnd)
    Debug.Print dtStart, dtEnd, "=>", dtStart - dtEnd

Output:

code:

27-3-2005 1:00:00           27-3-2005 4:00:00           =>             3 
27-3-2005 1:00:00           27-3-2005 4:00:00           =>            -0,125

En om 0:30 beginnen:

Visual Basic:

    Dim dtPL As Date
    Dim dtDA As Date
    Dim T As Long
     
    dtDA = DateSerial(2005, 3, 27) + TimeSerial(0, 30, 0)
    dtPL = dtDA
    For T = 0 To 5
        dtDA = DateAdd("h", 1, dtDA)
        dtPL = dtPL + 1 / 24
        Debug.Print dtDA, dtPL
    Next

Output:

code:

27-3-2005 1:30:00           27-3-2005 1:30:00 
27-3-2005 2:30:00           27-3-2005 2:30:00 
27-3-2005 3:30:00           27-3-2005 3:30:00 
27-3-2005 4:30:00           27-3-2005 4:30:00 
27-3-2005 5:30:00           27-3-2005 5:30:00 
27-3-2005 6:30:00           27-3-2005 6:30:00

Erkens schreef op dinsdag 16 augustus 2005 @ 14:42:
[...]

Opzich snap ik dat data type wel, want wat nu als je met een tijd wilt werken van bijvoorbeeld een server die in een andere tijdzone zit zonder die zomertijd? Maar ik ben het wel met je eens dat als je lokaal met een tijd moet werken dan moet je wel de mogelijkheid hebben om rekening te houden _met_ zomertijd.

Dat is denk ik het hele eiereneten: Hoe reken je met datums? Zolang je in een datum geen tijdzones zou aangeven (GMT, CET etc) e.d. kun je daar weinig over zeggen lijkt me. En dus kiest VB (ik denk vele andere talen ook) gewoon de makkelijkste/logischte weg lijkt me.

[ Voor 43% gewijzigd door RobIII op 16-08-2005 14:45 ]

[Maasluip]

.oisyn schreef op dinsdag 16 augustus 2005 @ 14:37:
Dat hele Date type is dus nog een grotere WTF?! dan de code die ermee gemoeid is . Hoe kun je hier nou reliable code mee schrijven

Zoals ik al schreef, een Date is een double die alleen anders gerepresenteerd wordt. En in principe, zolang het OS maar zomertijd-aware is kan er niks mis gaan. Als Windows maar weet dat 2:30 op 27-03-2005 betekent dat het 3:00 is gaat het goed. Ik weet niet of Windows het goed doet maar ik wel dat VMS er niet mee om kan gaan. Een job om 2:30 schedulen is vragen om problemen bij de omzetting naar zomertijd. Ik schedule zelf dus ook nooit iets tussen 2 en 3, omdat ik er gewoon van uit ga dat het niet goed gaat (ik hoor graag of Windows er wel mee om kan gaan).

[.oisyn]

Erkens schreef op dinsdag 16 augustus 2005 @ 14:42:
Opzich snap ik dat data type wel, want wat nu als je met een tijd wilt werken van bijvoorbeeld een server die in een andere tijdzone zit zonder die zomertijd?

Ligt eraan hoe die data binnenkomt. Het enige probleem dat je hebt is bij conversie van en naar tekst, en dan heb je tijdzone informatie nodig om dat goed te interpreteren. Intern kun je met een binair formaat werken waarin 27-3-2005 4:00 altijd 1 uur verder is dan 27-3-2005 2:00. Pas bij de conversie terug naar een leesbare datum moet je rekening houden met de wensen van de gebruiker. Meestal werk je intern dan ook gewoon in UTC (= GMT), die doet niet aan zomertijd, en dat wordt dan meestal gedaan met een simpele integer waarde die het aantal seconden of milliseconden of whatever resolutie je wilt sinds een bepaalde datum (Unix' time wordt het meest gebruikt: aantal seconden sinds 1 januari 1970 0:00 GMT)

[RobIII]

Maasluip schreef op dinsdag 16 augustus 2005 @ 14:45:
[...]
Zoals ik al schreef, een Date is een double die alleen anders gerepresenteerd wordt. En in principe, zolang het OS maar zomertijd-aware is kan er niks mis gaan. Als Windows maar weet dat 2:30 op 27-03-2005 betekent dat het 3:00 is gaat het goed. Ik weet niet of Windows het goed doet maar ik wel dat VMS er niet mee om kan gaan. Een job om 2:30 schedulen is vragen om problemen bij de omzetting naar zomertijd. Ik schedule zelf dus ook nooit iets tussen 2 en 3, omdat ik er gewoon van uit ga dat het niet goed gaat (ik hoor graag of Windows er wel mee om kan gaan).

Huh

Visual Basic:

If ScheduledDate<=CurrentDate then
  run_job
  ScheduledDate = DateAdd("d",1,ScheduledDate) 'Morgen weer...
end if

(Jaja, VB syntax, maar het gaat om het Idee... lees het maar als Pseudo code)

Lijkt me dat dat op elk systeem goed gaat? Ik weet niet hoe VMS die jobs scheduled, maar dat zou 'ie toch moeten "zien"? Bij mijn weten *(maar ik heb geen zin om 't te testen) gaat dit onder Windows gewoon goed?

.oisyn schreef op dinsdag 16 augustus 2005 @ 14:46:
[...]


Ligt eraan hoe die data binnenkomt. Het enige probleem dat je hebt is bij conversie van en naar tekst, en dan heb je tijdzone informatie nodig om dat goed te interpreteren.

quote: http://gathering.tweakers...message/23986255#23986255

Dat is denk ik het hele eiereneten: Hoe reken je met datums? Zolang je in een datum geen tijdzones zou aangeven (GMT, CET etc) e.d. kun je daar weinig over zeggen lijkt me. En dus kiest VB (ik denk vele andere talen ook) gewoon de makkelijkste/logischte weg lijkt me.

[ Voor 47% gewijzigd door RobIII op 16-08-2005 14:53 ]

[.oisyn]

RobIII schreef op dinsdag 16 augustus 2005 @ 14:43:
En dus kiest VB (ik denk vele andere talen ook) gewoon de makkelijkste/logischte weg lijkt me.

Nee, VB kiest hier de weg van de prutser die zelf even z'n datum-type denkt te implementeren. VB.Net heeft het wel beter geregeld, maar ja, die gebruikt dan ook gewoon een System.DateTime, waar je wél zinnige dingen mee kunt doen

Maasluip schreef op dinsdag 16 augustus 2005 @ 14:45:
[...]
Zoals ik al schreef, een Date is een double die alleen anders gerepresenteerd wordt.

Dat wil nog niet zeggen dat bij conversie van en naar tekst er met een locale rekening gehouden kan worden. Zoals ik in mijn vorige post zei, een date type is meestal niet meer dan een enkel getal en niet een combinatie van dag,maand,jaar en weetikniewat.

En in principe, zolang het OS maar zomertijd-aware is kan er niks mis gaan.

Het punt is dat het OS hier niets mee van doen heeft. Als ik met VB een programma maak waarin ik 2 datums op kan geven om het tijdsduur daartussen uit te rekenen, dan verwacht ik dat dat programma mijn eigen instellingen meeneemt in het interpreteren van de datum, en vervolgens de berekening doet. Echter, met VB6 komt er 3 uur uit als ik 27-3-2005 1:00 en 27-3-2005 4:00 opgeef, terwijl er toch echt maar 2 uur tussen zitten. Het OS kan het dus wel, alleen het Date type vraagt niets van het OS maar doet het allemaal maar lekker zelf.

(ik hoor graag of Windows er wel mee om kan gaan).

Elk zichzelf respterend OS kan ermee omgaan. Het is gewoon een kwestie van denken in de daadwerkelijk verstreken tijd, ipv de rare notatiewijze die wij mensen eraan gebonden hebben. Op dezelfde manier betekent 3 ook gewoon 3, of je dat nou binair, decimaal of hexadecimaal noteert. Het is ook niet zo dat als je een hexadecimaal getal opgeeft dat dat anders wordt opgeslagen (een bekende beginnersfout overigens ), het is gewoon een notatiewijze, net als met datums.

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 14:53:
Elk zichzelf respterend OS kan ermee omgaan. Het is gewoon een kwestie van denken in de daadwerkelijk verstreken tijd, ipv de rare notatiewijze die wij mensen eraan gebonden hebben. Op dezelfde manier betekent 3 ook gewoon 3, of je dat nou binair, decimaal of hexadecimaal noteert. Het is ook niet zo dat als je een hexadecimaal getal opgeeft dat dat anders wordt opgeslagen (een bekende beginnersfout overigens ), het is gewoon een notatiewijze, net als met datums.

100% Eensch is.

.oisyn schreef op dinsdag 16 augustus 2005 @ 14:53:
VB.Net heeft het wel beter geregeld, maar ja, die gebruikt dan ook gewoon een System.DateTime, waar je wél zinnige dingen mee kunt doen

Visual Basic .NET:

        Dim dtStart As System.DateTime
        Dim dtEnd As System.DateTime

        dtStart = DateSerial(2005, 3, 27) + " " + TimeSerial(1, 0, 0)

Het feit dat ik hier een spatie tussen beide moet toevoegen doet mij vrezen dat een System.DateTime intern als string wordt opgeslagen? (Helaas ben ik nog steeds niet erg thuis in VB.Net, dus wellicht kan het anders). Als ik echter dtStart = DateSerial(2005, 3, 27) + TimeSerial(1, 0, 0) probeer krijg ik een error dat 't een ongeldige datum is.

De volgende code geeft als resultaat echter ook doodleuk 3:

Visual Basic .NET:

        Dim dtStart As System.DateTime
        Dim dtEnd As System.DateTime

        dtStart = DateSerial(2005, 3, 27) + " " + TimeSerial(1, 0, 0)
        dtEnd = DateSerial(2005, 3, 27) + " " + TimeSerial(4, 0, 0)
        MsgBox(DateDiff(DateInterval.Hour, dtStart, dtEnd), MsgBoxStyle.OKOnly, "Test")

Maar nogmaals: Wellicht pak ik het verkeerd aan. VB.Net is nog niet echt onder de knie hier

[ Voor 62% gewijzigd door RobIII op 16-08-2005 15:11 ]

[remco_k]

RobIII schreef op dinsdag 16 augustus 2005 @ 14:30:
[...]

Uren optellen:

Visual Basic:

    Dim dtPL As Date
    Dim dtDA As Date
    Dim T As Long
    
    dtDA = DateSerial(2005, 3, 27) + TimeSerial(0, 0, 0)
    dtPL = dtDA
    For T = 0 To 5
        dtDA = DateAdd("h", 1, dtDA)
        dtPL = dtPL + 1 / 24
        Debug.Print dtDA, dtPL
    Next

Output:

code:

27-3-2005 1:00:00           27-3-2005 1:00:00 
27-3-2005 2:00:00           27-3-2005 2:00:00 
27-3-2005 3:00:00           27-3-2005 3:00:00 
27-3-2005 4:00:00           27-3-2005 4:00:00 
27-3-2005 5:00:00           27-3-2005 5:00:00 
27-3-2005 6:00:00           27-3-2005 6:00:00

Dit: dtPL = dtPL + 1 / 24 Is hetzelfde als dtPL = dtPL + 0, dus dat er niets gebeurd met de datum klopt. En ook dit is een veel voorkomende bug, met name bij berekeningen van percentages, en data's.
Deze getallen worden als int behandeld. Het zou wel goed moeten gaan als je dit doet:
dtPL = dtPL + 1.0 / 24.0
(tenminste, in bcb gaat dit prima en word er 1 uur bij opgeteld.)

btw, zomer/winter tijd zal je nooit zien verspringen in deze code. Als jij er een uur bij op wilt tellen, dan kan je er gewoon een uur bij optellen, ook al is de uitkomst een tijdstip wat nooit voorkomt.

Tot slot nog de final tip van mij: Als je met datums rekent - reken dan ALTIJD met UTC datums. Pas als de datum moet worden weergegeven, dan ga je mbv windows functies oid omrekenen naar lokale tijd.

[ Voor 29% gewijzigd door remco_k op 16-08-2005 15:13 . Reden: Onnodige vreselijk grote quote weggeknipt... ]

[RobIII]

remco_k schreef op dinsdag 16 augustus 2005 @ 14:55:
Dit: dtPL = dtPL + 1 / 24 Is hetzelfde als dtPL = dtPL + 0, dus dat er niets gebeurd met de datum klopt. En ook dit is een veel voorkomende bug, met name bij berekeningen van percentages, en data's.

Heb je de output bekeken? Het doet wel degelijk iets hoor?

remco_k schreef op dinsdag 16 augustus 2005 @ 14:55:
Deze getallen worden als int behandeld. Het zou wel goed moeten gaan als je dit doet:
dtPL = dtPL + 1.0 / 24.0

Het gaat gewoon goed? Hoewel het inderdaad wel eens gevaarlijk kan zijn dit soort constructies te gebruiken, wordt in dit geval (juist omdat een Date variabele geen int is) geen int maar een double gebruikt.

remco_k schreef op dinsdag 16 augustus 2005 @ 14:55:
btw, zomer/winter tijd zal je nooit zien verspringen in deze code. Als jij er een uur bij op wilt tellen, dan kan je er gewoon een uur bij optellen, ook al is de uitkomst een tijdstip wat nooit voorkomt.

Daar waren we al achter...

remco_k schreef op dinsdag 16 augustus 2005 @ 14:55:
Tot slot nog de final tip van mij: Als je met datums rekent - reken dan ALTIJD met UTC datums. Pas als de datum moet worden weergegeven, dan ga je mbv windows functies oid omrekenen naar lokale tijd.

En ook dat was al geconcludeerd

offtopic:
Het wordt wat overzichtelijker als je alleen relevante stukken quote, die hele lap is compleet overbodig. Ik zou een edit dan ook op prijs stellen

[ Voor 14% gewijzigd door RobIII op 16-08-2005 15:08 ]

[.oisyn]

remco_k schreef op dinsdag 16 augustus 2005 @ 14:55:
Dit: dtPL = dtPL + 1 / 24 Is hetzelfde als dtPL = dtPL + 0, dus dat er niets gebeurd met de datum klopt. En ook dit is een veel voorkomende bug, met name bij berekeningen van percentages, en data's.

Als dat zo was zou de test output hebben, omdat de DateAdd de datum wél verandert. Daarnaast is dit VB, geen C++, waarin een deling met de / wel een reëel getal op kan leveren, ook al deel je 2 integers. Als je echt een integer deling wilt moet je de \ gebruiken.

Tot slot nog de final tip van mij: Als je met datums rekent - reken dan ALTIJD met UTC datums. Pas als de datum moet worden weergegeven, dan ga je mbv windows functies oid omrekenen naar lokale tijd.

Mijn opmerknig was juist dat het Date type dat zou moeten doen, die is daar tenslotte voor.

[remco_k]

RobIII schreef op dinsdag 16 augustus 2005 @ 15:06:
[...]

Heb je de output bekeken? Het doet wel degelijk iets hoor?
Het gaat gewoon goed?

Oja? :
>> 27-3-2005 1:00:00 27-3-2005 1:00:00
Ik zie 2 dezelfde tijdstippen... volgens mij was het doel om er een uur bij op te tellen (gezien de 1/24)

....
En ook dat was al geconcludeerd

mja, remco_k kan niet alles lezen....

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 15:10:
Mijn opmerknig was juist dat het Date type dat zou moeten doen, die is daar tenslotte voor.

Heb je mijn edit gezien betreffende VB.Net?

remco_k schreef op dinsdag 16 augustus 2005 @ 15:11:
[...]

Oja? :

Ja
Er worden namelijk 2 variabelen ge-output en die lopen allebei OP (je moet van boven naar beneden lezen). Je moet het dus zien als 2 kolommen. Dit is gedaan om aan te tonen dat beide manieren dezelfde resultaten opleveren. Dus:

code:

dtDA                        dtPL
27-3-2005 1:00:00           27-3-2005 1:00:00 
27-3-2005 2:00:00           27-3-2005 2:00:00 
27-3-2005 3:00:00           27-3-2005 3:00:00 
27-3-2005 4:00:00           27-3-2005 4:00:00 
27-3-2005 5:00:00           27-3-2005 5:00:00 
27-3-2005 6:00:00           27-3-2005 6:00:00

[ Voor 59% gewijzigd door RobIII op 16-08-2005 15:15 ]

[remco_k]

RobIII schreef op dinsdag 16 augustus 2005 @ 15:12:
Ja
Er worden namelijk 2 variabelen ge-output en die lopen allebei OP (je moet van boven naar beneden lezen). Je moet het dus zien als 2 kolommen. Dit is gedaan om aan te tonen dat beide manieren dezelfde resultaten opleveren.

omg...
Ik zit te slapen, je hebt helemaal gelijk... Ik had al die tijd deze code in m'n hoofd:
dtPL = dtPA + 1 / 24 ipv dtPL = dtPL + 1 / 24 (wat er dus staat...)
Vandaar dat ik dacht dat het fout zou gaan.
In bcb c++ zou het overigens wel foutgaan en blijft dtPL op 27-3-2005 0:00:00 staan.

[RobIII]

remco_k schreef op dinsdag 16 augustus 2005 @ 15:20:
In bcb c++ zou het overigens wel foutgaan en blijft dtPL op 27-3-2005 0:00:00 staan.

A) is het maar wat je als "fout" interpreteert (misschien was het wel de bedoeling ) en [norml]B)[/] ging het over VB6 en niet BCB C++

[ Voor 3% gewijzigd door RobIII op 16-08-2005 15:41 ]

[.oisyn]

Nee had edit niet gelezen

RobIII schreef op dinsdag 16 augustus 2005 @ 14:55:

Visual Basic .NET:

        Dim dtStart As System.DateTime
        Dim dtEnd As System.DateTime

        dtStart = DateSerial(2005, 3, 27) + " " + TimeSerial(1, 0, 0)

Het feit dat ik hier een spatie tussen beide moet toevoegen doet mij vrezen dat een System.DateTime intern als string wordt opgeslagen? (Helaas ben ik nog steeds niet erg thuis in VB.Net, dus wellicht kan het anders).

Nee, System.DateTime gebruikt een 64 bits int als datatype

In Visual Basic .NET, the Date data type uses the common language runtime DateTime data type, which is an eight-byte integer value. Because of these different representations, there is no implicit conversion between the Date and Double data types. To convert between Double and the Visual Basic 6.0 representation of Date, use the ToOADate and FromOADate methods of the DateTime structure in the System namespace.

Ik vermoed dat het probleem met die spatie is dat VB.Net geen operator overloading kent, en VB het dus converteert naar een String (met de ToString() methode). De spatie is dan nodig omdat je anders de tijd direct achter de datum plaatst: "1-1-200523:54" ipv "1-1-2005 23:54". Maar dit is slechts een vermoeden, ik ben zelf ook niet bekend met VB.Net of zelfs de .Net API in het algemeen. Maar de DateTime (value) class is iig een stuk uitgebreider dan VB6's Date type

Heb het even geprobeerd met C++, de DateTime is ook wel raar hoor:

C++:

using namespace System;

int main()
{
    DateTime a (2005, 3, 27, 0, 30, 0, DateTimeKind::Utc);
    DateTime b = a.AddHours(24);

    Console::WriteLine("a = {0}, IsDayLightSaving={1}", a.ToLocalTime(), a.IsDaylightSavingTime());
    Console::WriteLine("b = {0}, IsDayLightSaving={1}", b.ToLocalTime(), b.IsDaylightSavingTime());
    Console::WriteLine("");

    DateTime c (2005, 3, 27, 0, 30, 0, DateTimeKind::Local);
    DateTime d = c.AddHours(24);

    Console::WriteLine("c = {0}, IsDayLightSaving={1}", c, c.IsDaylightSavingTime());
    Console::WriteLine("d = {0}, IsDayLightSaving={1}", d, d.IsDaylightSavingTime());
}

Output:

code:

a = 27-3-2005 1:30:00, IsDayLightSaving=False
b = 28-3-2005 2:30:00, IsDayLightSaving=False

c = 27-3-2005 0:30:00, IsDayLightSaving=False
d = 28-3-2005 0:30:00, IsDayLightSaving=True

Zoals je ziet, als het in UTC is gespecificeerd werkt het prima. In localtime is 24 uur erbij optellen gewoon een dag erbij optellen, terwijl dat toch een beetje krom overkomt. Hij zegt wel dat de datum dan in daylightsavings zit. Als ik er 2 uur bij optel (zodat hij op 2:30 uitkomt, wat niet bestaat) zegt hij niet dat hij in daylight savings zit, bij 3 uur erbij wel

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 15:44:
Maar de DateTime (value) class is iig een stuk uitgebreider dan VB6's Date type

Dat zal ik niet ontkennen VB6 is in een flink aantal opzichten dan ook een aardig museumstuk aan 't worden.

.oisyn schreef op dinsdag 16 augustus 2005 @ 15:44:
Heb het even geprobeerd met C++, de DateTime is ook wel raar hoor:
<knip>

Dus VB6 is niet de enige die "raar" doet
Ik zie trouwens net dat je bij a en b wel .ToLocalTime gebruikt en bij c en d niet. Nu doe je dat natuurlijk omdat het local time zou moeten zijn, maar probeer het er eens op te knallen?

[ Voor 18% gewijzigd door RobIII op 16-08-2005 15:50 ]

[.oisyn]

Roflol

C++:

using namespace System;

int main()
{
    DateTime c (2005, 3, 27, 0, 30, 0, DateTimeKind::Local);
    DateTime d = c.AddHours(3);

    Console::WriteLine(d - c);
    Console::WriteLine(d.ToUniversalTime() - c.ToUniversalTime());
}

output:

code:

03:00:00
02:00:00

Ik heb er 3 uur bij opgeteld, in localtime is dat idd 3 uur, maar in UTC is dat slechts 2 uur

.edit: andersom ook overigens, als ik 2 datums construct in de locale tijdzone: 27-3-2005 0:30 en 27-3-2005 3:30, dan zegt ie dat het verschil daartussen 3 uur is, terwijl het toch echt 2 uur is.

Ik ga microsoft eens contacten

.edit2: @RobIII, nee, was wat vergeten weg te cutten voordat ik hier postte

[ Voor 39% gewijzigd door .oisyn op 16-08-2005 16:14 ]

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 16:07:
Roflol

Ik mis wat output volgens mij? Maar wel vaaaaag ja

.oisyn schreef op dinsdag 16 augustus 2005 @ 16:07:
.edit2: @RobIII, nee, was wat vergeten weg te cutten voordat ik hier postte

Ach so...

[ Voor 37% gewijzigd door RobIII op 16-08-2005 16:17 ]

[.oisyn]

Ah, hier wat meer info die dit allemaal confirmt: http://msdn.microsoft.com...net/html/datetimecode.asp

Performing date and time calculations on values that represent machine local time may not always yield the correct result. When performing calculations on time values in time-zone contexts that practice daylight savings time, you should convert values to universal time representations before performing date arithmetic calculations.

Dat is natuurlijk wel een leuke en werkende oplossing, maar ik blijf erbij dat ik het krom vind. Een tijdstip is een tijdstip, ongeacht de tijdzone waarin dat tijdstip gedefinieerd is. Als ik bij een datum 3 uur optel, dan verwacht ik dat het verschil tussen die datums ook daadwerkelijk 3 uur is, ongeacht de tijdzone waarin die datums gespecificeerd zijn. Ik vind het dan ook nogal onjuist gedesigned, en ik denk dat als ik ooit iets met datums zou moeten doen ik mijn eigen datum class maak gebaseerd op een DateTime in UTC.

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 16:23:
Als ik bij een datum 3 uur optel, dan verwacht ik dat het verschil tussen die datums ook daadwerkelijk 3 uur is, ongeacht de tijdzone waarin die datums gespecificeerd zijn.

Spreek je nu jezelf niet tegen? Dat was toch precies wat VB6 doet/deed?
Volgens mij lullen we compleet langs elkaar hier allemaal Ik kan er geen touw meer aan vastknopen

[ Voor 13% gewijzigd door RobIII op 16-08-2005 16:26 ]

[.oisyn]

Het punt is ook dat het min of meer hetzelfde is als wat in VB gebeurt, wat ik dus slecht vind

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 16:42:
Het punt is ook dat het min of meer hetzelfde is als wat in VB gebeurt, wat ik dus slecht vind

Ah, daar is mijn kluts
En het topic Want ik miste opeens een bult replies

Enniehoe, ik kijk er eerlijk gezegd niet eens echt van op. Het zou namelijk ook wel een bult overhead betekenen als alles "zomaar automatisch" ging. Dan zou de uiteindelijke code (*) bij iedere actie op een DateTime var moeten kijken welke tijdzone, wat de verschillen zijn, correcties er op los laten enz. en dat lijkt me in de meeste gevallen niet eens wenselijk en verspilling van CPU cycles.

(*) Dat zou natuurlijk de taak moeten zijn van de compiler / base libraries e.d.

[ Voor 54% gewijzigd door RobIII op 16-08-2005 16:47 ]

[.oisyn]

Ik heb er net even over na zitten denken, en je moet het toch wel doen. Sowieso, bij eenheden kleiner dan een dag (AddHour, AddMinute, etc.) hoeft het niet. Bij dagen, maanden en jaren wel, maar bij maanden en jaren moet je sowieso al kijken naar hoe de datum valt in een bepaalde tijdzone. Want intern werkt het met een int64 dat het aantal milliseconden sinds 1-1-1 0:00 UTC weergeeft. Je moet voor maanden en jaren dus altijd kijken naar hoe de huidige datum valt om te berekenen hoeveel milliseconden je erbij moet tellen. Het enige is dat dat voor dagen momenteel niet hoeft, maar zo moeilijk is het niet: kijk of de oude datum in daylight savings valt (boolean a), en of de nieuwe datum in daylightsavings valt (boolean b). Als !a && b, dan 1 uur extra erbij. Als a && !b, dan 1 uur eraf. Anders niets.

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 16:55:
Ik heb er net even over na zitten denken, en je moet het toch wel doen. Sowieso, bij eenheden kleiner dan een dag (AddHour, AddMinute, etc.) hoeft het niet. Bij dagen, maanden en jaren wel, maar bij maanden en jaren moet je sowieso al kijken naar hoe de datum valt in een bepaalde tijdzone. Want intern werkt het met een int64 dat het aantal milliseconden sinds 1-1-1 0:00 UTC weergeeft. Je moet voor maanden en jaren dus altijd kijken naar hoe de huidige datum valt om te berekenen hoeveel milliseconden je erbij moet tellen. Het enige is dat dat voor dagen momenteel niet hoeft, maar zo moeilijk is het niet: kijk of de oude datum in daylight savings valt (boolean a), en of de nieuwe datum in daylightsavings valt (boolean b). Als !a && b, dan 1 uur extra erbij. Als a && !b, dan 1 uur eraf. Anders niets.

Ja, maar dat zou dus betekenen dat je bij iedere operatie op een datetime 2x moet controleren of het nou wel of niet in daylightsavings valt. En ook als je een (milli)seconde of minuut optelt/aftrekt overigens (hoewel dat te optimaliseren zou zijn door het niet te doen als het buiten 2:00/3:00 valt ofzo...).
Ik vind het dus "werk van de programmeur" en niet van "de compiler" of whatever om dit soort dingen te vangen. Als je er uberhaupt al behoefte aan hebt met dit soort dingen rekening te houden.

[ Voor 9% gewijzigd door RobIII op 16-08-2005 17:01 ]

[.oisyn]

RobIII schreef op dinsdag 16 augustus 2005 @ 16:59:
En ook als je een (milli)seconde of minuut optelt/aftrekt overigens (hoewel dat te optimaliseren zou zijn door het niet te doen als het buiten 2:00/3:00 valt ofzo...).

Nee, want dan tel je simpelweg een aantal milliseconden bij je int op. Er verandert niets aan die int of het nou in daylight savings is of niet. Pas bij het converteren naar een string (!!!) moet je bepalen welke tijd het nou eigenlijk is.

[RobIII]

.oisyn schreef op dinsdag 16 augustus 2005 @ 17:54:
[...]


Nee, want dan tel je simpelweg een aantal milliseconden bij je int op. Er verandert niets aan die int of het nou in daylight savings is of niet. Pas bij het converteren naar een string (!!!) moet je bepalen welke tijd het nou eigenlijk is.

U heeft geheel gelijk. Da's al de tweede keer vandaag dat je me weer op het juiste spoor zet

[ Voor 4% gewijzigd door RobIII op 16-08-2005 18:08 ]

[Woy]

IDD eigenlijk zou je ook helemaal geen ToLocal en ToUniversalTime hoeven te hebben je zou alleen een override van ToString ( en aanverwanten ) moeten hebben die aangeeft in welke zone je de tijd wilt weergeven.

Eventueel nog een ToLocal en ToUniversal die alleen intern een prefference zet zodat alle functies die een datum weergeven standaard die instelling gebruiken.