[Robert]

Fick se att en web jag har gjort har "skottårs bugg" i en kalenderfunktion även då den använder IIS 6.0 och dess datumfunktioner. Såg även att ett forum jag ofta besöker (PHP) har denna bugg....

Så jag undrar: har ni kollat era rutiner så de fungerar med skottår? (ja, det är ju denna månad som har 1 dag extra, nämligen den 29:e...).

Själv orkar jag inte rätta denna bugg då den "bara" dyker upp 1 gång var 4:e år....förhoppningsvis så är detta system skrotat då... B)

[Marcus]

är väl inte direkt svårt att kolla om det är skottår eller ej?
[ året jämnt delbart med fyra == skottår ]
ex.vis:
2004/4=501 [501==heltal; alltså skottår]

fast det var kanske något annat du tänkte på?

[Robert]

Nja, det är ju inte svårt, det var inte det jag menade. Jag bara undrade om alla har med skottår i sina beräkningar, så inte tex orderläggningar etc förlorar en dag, eller att systemet får tuppjuck om det är multi tier där båda skikt har en datumfunktion och dessa kommer att missmatcha den 29:e....


Grejjen var att jag använder en inbyggd datumfunktion som bör veta om det är skottår eller ej...så det finns kanske andra system därute som hanterar detta felaktigt

[zmodem]

Originally posted by marcuss@Feb 17 2004, 18:08
är väl inte direkt svårt att kolla om det är skottår eller ej?
[ året jämnt delbart med fyra == skottår ]
ex.vis:
2004/4=501 [501==heltal; alltså skottår]

riktigt så enkelt är det väl nu inte...
skottår är det de år som är jämnt delbara med fyra (t.ex. 2004) utom vid sekelskiften som inte är jämnt delbara med 400.

Alltså: 2004 = skottår
1900 = inte skottår
2000 = skottår


själv använder jag Perls inbygda funktioner för datum och tid (som i sin tur bygger på standardfunktionerna i C-biblioteket) och liter på att den har koll på skottåren.

Men det blir problem sedan (tror det var typ år 2034) när antalet sekunder sedan 1970 inte längre får plats i en 32-bit unsigned integer. Det blir ju lite spännande...

[Lundmark]

Man kan ju dela 2000 med 4 och få 500, alltså ett heltal, eller vad menar du?

[erzki]

isLeapYear ASP

[Marcus]

Originally posted by zmodem@Feb 18 2004, 12:52
riktigt så enkelt är det väl nu inte...
skottår är det de år som är jämnt delbara med fyra (t.ex. 2004) utom vid sekelskiften som inte är jämnt delbara med 400.

Alltså: 2004 = skottår
1900 = inte skottår
2000 = skottår

okej, har man planer på att programmet ska hålla i 100 år från nu så kan det bli problem. visst.

och det är kanske fel att inte ha en heltäckande lösning. men det är ju lite skillnad på 20 år (~1980 till milleniumbuggen) och 100 år som nu är fallet, dvs år 2100.

...annars är ju lösningen precis sådär enkel just för att vi nyligen passerat ett årtusende OCH århundrade.

[Anders]

Originally posted by zmodem@Feb 18 2004, 11:52
Men det blir problem sedan (tror det var typ år 2034) när antalet sekunder sedan 1970 inte längre får plats i en 32-bit unsigned integer. Det blir ju lite spännande...

Jag tror vi klarar oss. Tror du inte vi kör 64-bitars då?

[zmodem]

Originally posted by lunne82@Feb 18 2004, 16:15
Jag tror vi klarar oss. Tror du inte vi kör 64-bitars då?

Jo men va fasen, då måste jag programmera om min hemsida jue :P

[Anders]

Ursprungligen postat av zmodem

Jo men va fasen, då måste jag programmera om min hemsida jue :P

Borde du ju inte behöva, du sa ju:
"själv använder jag Perls inbygda funktioner för datum och tid (som i sin tur bygger på standardfunktionerna i C-biblioteket) och liter på att den har koll på skottåren."
I så fall kommer ju allt funka bra, eller finns det fler begränsningar?