Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: negative time_t values
Message-ID: <5638@ut-sally.UUCP>
Date: Fri, 29-Aug-86 14:51:09 EDT
Article-I.D.: ut-sally.5638
Posted: Fri Aug 29 14:51:09 1986
Date-Received: Fri, 29-Aug-86 21:35:22 EDT
Organization: IEEE 1003 Portable Operating System for Computer Environments
Committee
Lines: 31
Keywords: RFC.001, timezones
Approved: j...@sally.UUCP
From: elsie!...@seismo.UUCP
Date: Mon, 25 Aug 86 18:35:05 EDT
Subject: negative time_t values
While it's true that no UNIX files date back to before January 1, 1970,
there *are* uses for times before that epoch: in personnel data bases where
birth dates are recorded; in data bases recording astronomical events;
in stock market price data bases (as used by chartist fanatics); and elsewhere.
(And what of all those old 7094 executables that are being used on IBM machines
running UNIX or a cousin? :-))
I see more use in the short run for being able to record times between
1901 and 1970 that I see for being able to record times after 2038.
And if we do make it into the twenty-first century, I imagine we'll be working
on machines with 256-bit registers where time_t will have a type that allows
it to represent times into the very distant future; if it's defined properly,
time_t variables will also be able to represent times into the very distant
past.
In summary: I'd recommend retaining the ability for time_t variables to
represent times before 1970.
--
UNIX is an AT&T registered trademark.
Time is a Time/Life Incorporated trademark.
IBM is an IBM trademark.
--
UUCP: ..decvax!seismo!elsie!ado ARPA: elsie!...@seismo.ARPA
DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.
Volume-Number: Volume 6, Number 41
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: negative time_t values
Message-ID: <5661@ut-sally.UUCP>
Date: Wed, 3-Sep-86 23:42:05 EDT
Article-I.D.: ut-sally.5661
Posted: Wed Sep 3 23:42:05 1986
Date-Received: Thu, 4-Sep-86 21:38:09 EDT
Organization: IEEE 1003 Portable Operating System for Computer Environments
Committee
Lines: 49
Approved: j...@sally.UUCP
From: sun!gorodish!...@utastro.UUCP (Guy Harris)
Date: Sat, 30 Aug 86 20:39:06 PDT
> While it's true that no UNIX files date back to before January 1, 1970,
> there *are* uses for times before that epoch:
Yes, but there are other representations for such dates and times; there's
no particular need to have "time_t" objects represent dates in 4004 BCE, for
example. Most of the time, they are represented as mixed-radix numbers,
giving year, month, day, etc., or year, day of year, etc.. The standard
arithmetic functions on dates (date1 - date2, date1 + offset, etc.) are
possible, if slightly less convenient, as are comparisons of dates. Most of
the examples given don't currently use "time_t", as they're not done on UNIX
systems, and there's no good reason to change them and not much reason to
use "time_t" for future programs of those sorts. ("time_t" is an especially
poor choice for astronomical event databases; many interesting such events
occurred more than 68 years before 1970....)
> I see more use in the short run for being able to record times between
> 1901 and 1970 that I see for being able to record times after 2038.
Yes, but is there a use for recording UNIX file modification times between
1901 and 1970? Other times can be recorded in forms other than a "time_t".
> In summary: I'd recommend retaining the ability for time_t variables to
> represent times before 1970.
It's not a case of "retaining". The 1003.1 Trial-Use Standard says that the
result of "time" represents "the value of times in seconds *since* 00:00:00
GMT, January 1, 1970" (italics mine), and that the values of the time fields
in a "stat" structure are also times since the epoch. All definitions of
"since" in the Webster's Third in my office indicate that it refers to times
in the future of the associated event, so March 25, 1967, 18:00:00 GMT is
not a time since the epoch and is not a value that "time" will return, nor
is it a time that will appear in a "struct stat" time field.
Assigning a meaning to negative "time_t" values may be straightforward in
that it's done by replacing "since" with "before, at, or since"; however, it
does involve changes to existing UNIX implementations to permit them to be
interpreted as local times (even with table-driven time zone conversion
routines, one has to get the tables right!). Few, if any, existing programs
deliberately store negative values in "time_t" variables; many of those
programs are likely to want to store times more than +/- 68 years from the
epoch, so liberalizing the meaning of "time_t" isn't going to help them.
They'll have to wait for the hypothetical time in the future when "time_t"
is made a "long long int" or when all 32-bit machines have been replaced by
64-bit machines to make "time_t" useful to them.
Volume-Number: Volume 6, Number 42
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-u...@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: negative time_t values
Message-ID: <5728@ut-sally.UUCP>
Date: Mon, 15-Sep-86 10:57:00 EDT
Article-I.D.: ut-sally.5728
Posted: Mon Sep 15 10:57:00 1986
Date-Received: Mon, 15-Sep-86 20:52:30 EDT
References: <5673@ut-sally.UUCP> <5663@ut-sally.UUCP>
Organization: IEEE 1003 Portable Operating System for Computer Environments
Committee
Lines: 36
Keywords: RFC.001, time zones
Approved: j...@sally.UUCP
From: cbosgd!cbosgd.ATT.COM!m...@seismo.UUCP (Mark Horton)
Date: Wed, 10 Sep 86 12:40:40 edt
Organization: AT&T Bell Laboratories, Columbus
There are many uses for dates, on which you'd like to be able
to do arithmetic. I don't see where the assumption that time_t
is only useful for file modification times got made. We have
an application that needs to be able to store birth dates of
people living today, and of their parents. We would like to be
able to use the same format for parents' birth dates and for
machine generated time stamps. And we'd like to be able to
easily add or subtract 3 hours, for example, from such a quantity.
Note that all the UNIX routines to deal with dates, such as ctime,
localtime, gmtime, and asctime, deal with time_t quantities. There
are no operations provided to manipulate a struct tm. This means
there's a huge penalty for any application that needs to manipulate
times that might be before 1970 or after 2038. They must implement
a set of primitives to manipulate a struct tm or other data structure
(such as an ISO format time string, which is also broken into year,
month, day, etc.)
Even if you offered us dates back to 1901, it wouldn't be enough for
our application. We have to go back to about 1850. But I would hope
to see some facilities added to manipulate a more general date/time
format than a time_t. Maybe the 4.2BSD struct timeval needs to have
another field added to indicate a base year (defaulting to 1970.)
Mark
[ There are manipulation (adding, subtracting) routines for timeval
in the 4.2BSD kernel, by the way, though they never seem to have been
brought out into a user-accessible library, even in 4.3BSD (except
for timerisset, timercmp, and timerclear in <sys/time.h>). -mod ]
Volume-Number: Volume 6, Number 47