[BC3] wat is hier mis, milleniumbug???

[valkenier]

Ik klik op de lettertype zou serieuzer moeten worden genomen link op de frontpage en ik kom uiteindelijk hier terecht:



hoe kan dat??

[IceStorm]

Gewoon een keer f5 raggen (of welke toets dat ook is in opera ).

Oh en als je het plaatje wil laten zien, haal dan even die spatie weg op het eind

edit:
Ah wacht, je krijgt een vage timestamp. Nou ja.. gewoon nog een keer proberen of ''blijft'' het?

[Verwijderd]

Hmm, unix timestamp

[valkenier]

ja sorry, ik heb het linkje even aangepast, maar hoe kom je nou in 1969 terecht??

[IceStorm]

In unix (?) is 1 januari 1970 standaard als ''geen datum''. Ik weet niet precies hoe het komt maar het is een ''terugkerende datum'' (in user profiles van niet bestaande users stond die datum ook als geboortedatum bijv.).

Ik hoop dat er iemand met ietsie meer kennis wat uitleg wil geven

[Femme]

Het linkje naar het lettertype artikeltje geeft bij mij gewoon een normale nieuwspagina. Met een timestamp van -86400 kom je idd ergens in 1969 terecht.

[Verwijderd]

Op maandag 28 mei 2001 22:39 schreef Femme het volgende:
Met een timestamp van -86400 kom je idd ergens in 1969 terecht.

lol

[valkenier]

maar ik heb die timestamp niet zelf verzonnen...

eigenlijk zag ik eerst dit:

[valkenier]

hlpdsk, dat snap ik wel, maar ik kreeg het gevoel dat Femme wilde zeggen: logisch dat je in 1969 uitkomt met zo''n timestamp.

dat geloof ik wel, maar het blijft toch raar dat dit gegenereerd wordt? Misschien dat mijn 2e screenshot de oplossing biedt?

[Verwijderd]

Op maandag 28 mei 2001 22:48 schreef valkenier het volgende:
maar ik heb die timestamp niet zelf verzonnen...

Nee, maar Unix wel. En de boel draait op variant daarop : Linux.

[Femme]

Ik krijg met geen mogelijkheid dat resultaat als ik naar 17072 ga. Het kan alleen gebeuren als er geen resultaten uit de database komen maar er geen connect error is geweest. In dat geval kan de timestamp 0 en haalt hij er 86400 seconde af voor de vorige dag.

[valkenier]

en 17067 ?

zou het dan toch aan casema liggen?

Het werkt bij mij inmiddels ook weer normaal overigens.

[BC3 Victim]

Op maandag 28 mei 2001 22:36 schreef IceStorm het volgende:
In unix (?) is 1 januari 1970 standaard als ''geen datum''. Ik weet niet precies hoe het komt maar het is een ''terugkerende datum'' (in user profiles van niet bestaande users stond die datum ook als geboortedatum bijv.).

Ik hoop dat er iemand met ietsie meer kennis wat uitleg wil geven

De epoch tijd:
De epoch tijd is een integer getal. Dat getal is het aantal secondes sinds 1 januari 1970. Als het getal null of 0 is, dan is het dus 1970. Ik geloof dat we nu ergens bij 98987665 zitten ofzo (ik kan er ergens naast zitten ). Maareh, dit is dus veel makkelijker rekenen als 21-04-2001. Lekker gekloot is dat met sorteren enzo. Als je dan op wil slaan in een db moet je 2 velden gebruiken, een voor de datum en een voor de tijd. Schiet niet op. De epoch tijd is dus errug handig, maar als hij ''niet gedefinieerd'' is, staat hij dus op 1 januari 1970!

[Femme]

Ik geloof dat we nu ergens bij 98987665 zitten ofzo

Het is nu 991090357 (nog ~103 dagen tot 999999999 )

[Wouter Tinus]

en iets na 2140000000 kreeg je een overflow toch? 2070 bug ofzo

[BC3 Victim]

Op dinsdag 29 mei 2001 00:50 schreef Femme het volgende:

[..]

Het is nu 991090357 (nog ~103 dagen tot 999999999 )

Damn tijd geleden dus dat ik hiermee heb gewerkt. Toen zaten we nog in de 989 range (en de lengte klopte ook niet echt )

[BC3 Victim]

Op dinsdag 29 mei 2001 00:53 schreef WouterTinus het volgende:
en iets na 2140000000 kreeg je een overflow toch? 2070 bug ofzo

Ik dacht 2014 ofzo.
Komt omdat je in een integer getal maar een x aantal waardes kan dumpen. En als hij dan te groot wordt, tja...

[Verwijderd]

unsigned int

max is: 2147483647

is => January 19, 2038, 4:14 am

[Verwijderd]

Bij de systemen van IBM is er toch een soortgelijke bug? Alleen een andere datum.