Rok 2038 - Was [Re: Protokol TCP/IP]

Jiri Kulhan jiri.kulhan na creatix.cz
Pondělí Září 20 10:27:38 CEST 1999



Oto tapik Buchta wrote:
> 
> Michal Krause wrote:
> >
> > Dne 19. 9. 1999 Ing. Pavel PaJaSoft Janousek napsal:
> >
> > > >    Samozrejme, ale na vetsine platforem to neni zrovna rok 2038, protoze C API
> > > > pokud vim nikde nespecifikuje, od ktereho casoveho okamziku se cas meri.
> > >
> > >       Nevim o platforme, kde by se v C API cas v zakladni funkci time ()
> > > meril jinak nez pocet sekund od 1.1.1970, vy ano?
> >
> > Zrovna nedavno me jeden clovek presvedcoval, ze ve Windows je to 1. 1. 1980.
> > Bohuzel to nemuzu potvrdit ani vyvratit, protoze tady zadna Wokna nemam a od
> > dob, kdy jsem pod nimi programoval, uz taky nejaky ten rok ubehl.
> >
> No kazdopadne ja bych tomu veril, nebot v DOSu tomu tak skytecne bylo
> (jen si vzpomente, ze kdyz jste vytahli resetovali CMOSku nebo nedej
> boze meli Xtuha
> bez baterky, meli jste cas 1.1.1980
> 
Drobne problemy se ocekavaji i na OpenVMS, i kdyz spise na strane
aplikaci, nebot nativni datovy format OpenVMS je jiny. DEC o tom doslova
pise :

DIGITAL recommends limiting all Year 2000 testing to dates
prior to 19-JAN-2038. Another industry-wide, date-related problem
will likely occur on that date at 03:14:07 GMT. The Year 2038
problem is analogous to the Year 2000 problem, but results from
overflows in the storage of time and date values in C programs.
The Year 2038 problem is expected to have minimal adverse
effects for the OpenVMS operating system because the C date
format is not the native date storage format used on OpenVMS. 

Jiri Kulhan

BTW: ten puvodni thread (myslim, ze se tykal annonce cs apache+php+ssl)
byl nejaky neuveritelne plodny :-))


Další informace o konferenci Linux