Date: Mon, 8 Jul 1996 16:28:37 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: lcurtis@intecom.com (Leon Curtis) Cc: FreeBSD-questions@FreeBSD.org Subject: Re: Handling time after 1999 Message-ID: <199607082328.QAA22948@phaeton.artisoft.com> In-Reply-To: <Pine.BSD.3.93.960708085242.80A-100000@lcurtis.intecom.com> from "Leon Curtis" at Jul 8, 96 09:08:12 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I have been asked to look into what other unix kernel groups are planning > to do to address problems with time when the year 2000 arrives. Nothing. But life will be a real bitch come 2038, when the 32 bit timeval's all roll over. > I would appreciate any pointers that would enable me to get "plugged in" > to any dialog / specifications relating to this issue. In general, new UNIX systems use a 64 bit time value, which should be sufficient for the next ~100 billion years. > I work for a company that owns a version of (real time) unix put out > by LynxOS (Los Gatos, California). Our PBX product runs this OS and will > be the benefactor of the time changes. The time problems most systems run into are the use of two character date input and storage fields. There is currently no problem with that for any software known to be on BSD. The typical failure case is for COBOL or "business FORTRAN" users who hard coded small date fields to meet input packing constraints (need to fit this teeny form onto the screen) or who implemented "easier input" mechanisms (to keep people from having to type "19" in front of their years). In general, this is *purely* a database/UI problem. In 2038, if the UNIX programmers used time_t like they were supposed to, then a simple recompile will fix the problem, with no additional changes necessary )(the file system already has reserved space for 64 bit dates). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607082328.QAA22948>