🚀 go-pugleaf

Pawlus Jerzy <yppawlus@cyf-kr.edu.pl> wrote:
> In pl.listserv.polip Rafal Maszkowski <rzm@rymunda.torun.pdi.net> wrote:
> : > W podanej wyzej konwecji mozemy byc spokojni tylko do roku 2147 :-).
> : Mozna sie jeszcze obawiac, ze niektore implementacje moga uzywac signed
> : zamiast unsigned, wtedy katastrofy groza nam wczesniej. Przepelnienie 32 bitow
> : powinno sie zdarzyc po 2^32/86400/365.25 = 136.1 latach. Prawidlowe daty
> : katastrof to:
> : 1970+136.09930083403047126524 = 2106.09930083403047126524
> : 1970+68.04965041701523563262 = 2038.04965041701523563262
> : Tej drugiej zapewne dozyje, wiec odczuwam pewien niepokoj...
>   Wydaje mi się, że mówimy o czymś innym. Dyskusja toczy się na temat
>   pola Serial w SOA, które może ale nie musi być powiązane z czasem.
>   W szczególności można sobie wyobrazić numerację poczynając od 1 z
>   każdorazowym zwiększeniem pola o 1 po zmianie zawartości rekordu.
>   Dlatego format postaci YYYYMMDDNN z całą pewnością wystarczy do
>   roku 2147 a prawdopodobnie i póżniej.
>   Ty natomiast poruszyłeś inny problem związany z reprezentacją daty
>   pod systemem Unix. Tutaj rzeczywiście mogą być kłopoty chociaż nie
>   wiem czy nie jest to liczba 64-bitowa.

Te problemy są ze sobą powiązane, jeżeli się używa konwencji yyyymmddnn
(gdzie nn może być też godziną), do której używania zachęcam. W roku
2038 możemy być zmuszeni do wolniejszego zwiększania nr seryjnego
żeby nie przekroczyć 2^31, ale z pewnością do tego czasu pole danych
do przechowywania nr seryjnego się zwiększy (o ile nie zmieni się coś
bardziej fundamentalnego), więc konwencję śmialo można polecać nawet
najmłodszym z nas. Natomiast należy odradzać konwencję z dwoma tylko
cyframi roku - to się zakończy katastrofą za 2.5 roku.

Skąd bierzesz rok 2147? Czy to ja źle policzyłem?

R.
-- 
Rafal Maszkowski rzm@torun.pdi.net           http://www.torun.pdi.net/~rzm
Opinia publiczna powinna byc zaalarmowana swoim nieistnieniem - St. J. Lec