Názory k článku
Dnes nastane kulatý unixový čas: 1200000000

GMT je greenwichský čas se započítáním přechodu na letní čas, je to tedy vždy SE(L)Č-1 h, to o čem píšeš je UTC, ten je jako GMT, akorát je u něj jen zimní čas, tedy SEČ-1 h, SELČ-2 h,

Jen jestli v tom cisle par nul nechybi - muj pocitac mne presvedcuje, ze onech 1200000000 bylo uz 14. ledna 1970. Jo kdyby tam bylo o 3 nuly vic, to by byla jina ..

Nie nie.

elvis@gandalf:~$ date -d @1200000000
Thu Jan 10 22:20:00 CET 2008

No jasne, jsem blb .. nejak mi nedoslo ze Unixovsky timestamp je v sekundach zatimco v Jave se pocita v milisekundach.

Takze beru zpet svou pripominku a omlouvam se.

$ date -d @$[011000000000]
So dub 12 02:19:12 CEST 2008

$ date -d @$[011111111111]
St lis 19 23:25:13 CET 2008

nebot jestli se nepletu, tak unixtimestamp ignoruje prestupne vteriny

Kdyz byla naposledy prestupna vterina, tak me zajimalo, jak to bude timestamp pocitat, ale nejak jsem se v tu dobu nedostal k pocitaci :-(

no kdyby je pocital, tak by to memohlo vyjit presne na 22:20, ale muselo byt to byt o ty prestupne vteriny mene, tady 22:19:27, takze nejspis je zcela ignuruje, nebo by stacilo si udelat rozdil mezi 12:00:00 1.1.2006 a 12:00:00 31.12.2005 (kdy o pulnoci tato vterina byla naposledy pridana) a pokud to vyjde presne 86400, tak opet potvrzeni, ze to ignuruje, pokud by s ni pocital, tak by to muselo vyjit 86401

Wikipedie http://en.wikipedia.org/wiki/Unix_time popisuje nekolik moznosti,
jak se UNIXove systemy chovaji pri pruchodu prestupnou sekundou.

-Y.

Pocet sekund od 1970-01-01 00:00:00 UTC nema s prestupnymi vterinami nic spolecneho.

mam si to vysvetlit tak, ze ani prestupny rok nema zadny vliv na pocet sekund od 1.1.1970?

Na počet sekund ne, ale na unix time ano. On ten POSIX.1 unix time vlastně není absolutní počet sekund, je to spíš jen jiné vyjádření normálního data.

The Unix time number increases by exactly 86 400 each day, regardless of how long the day is.

http://en.wikipedia.org/wiki/Year_2038_problem

Mno ako kde...:-D

[magic@prgmaga Share]$ date -d @2147483647
Ut jan 19 04:14:07 CET 2038
[magic@prgmaga Share]$ date -d @2147483648
Ut jan 19 04:14:08 CET 2038

M.

Kuzolniku, nenafejkoval si to? :)

A nenafejkoval veru. na x86_64 to prejde skrz. Potom to ale pretecie na roku.

Nemusel to fejkovat. většina systému má datový typ time_t definován jako long, takže na 64 bitových systémech (které obvykle používají LP64 datový model) budou v roce 2038 klidní, znervozní až o něco málo později, ale to už nebude problém naší generace. :-)
Ale neplatí to všude, třeba jsem si všimnul, že NetBSD3.x pro sparc64 jede time_t jen na 32 bitů?
Inu, ukáže se pak, kdo je prase a píše ve zdrojácích něco jako "int cas=time(NULL)" místo "time_t cas=time(NULL)". :-))

Já jsem psychopat, takže mám 32-bitový long a 64-bitový time_t. Ale spoustě programů se to taky nelíbí, mají v sobě zadrátováno, že sizeof(time_t) <= sizeof(long) a musejí se upravovat.

Všechno nejlepší do dalších 100 000 000s.

Já to trefil!!!

karlos@tuxik:~$ date +%s
1199999999
karlos@tuxik:~$ date +%s
1200000000
karlos@tuxik:~$ date +%s
1200000001

Na zdraví tedy! :-)