[mod.std.unix] negative time_t values

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (08/29/86)

From: elsie!ado@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!ado@seismo.ARPA
	DEC, VAX, Elsie & Ado are Digital, Borden & Ampex trademarks.


Volume-Number: Volume 6, Number 41

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/04/86)

From: sun!gorodish!guy@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

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/04/86)

From: hadron!jsdy@seismo.UUCP (Joseph S. D. Yao)
Date: Tue, 2 Sep 86 04:14:29 edt
Organization: Hadron, Inc., Fairfax, VA

In article <5638@ut-sally.UUCP> you write:
>From: elsie!ado@seismo.UUCP 
>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.

These should be recorded in the DATE format of your DBMS, not as a
longint!  If your DBMS has no DATE format (tsk!), it should be recorded
as three [or six] ints.  Yes, I know you'll have to compare via a
procedure instead of an op; see the (tsk!) above.

>(And what of all those old 7094 executables that are being used on IBM machines
>running UNIX or a cousin?  :-))

What of them?

>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.

Possibly.  But I plan to be living (and making plans) well into the
2000's.  I don't want to run up against a wall.  (I already have, in
that versions of Unix today don't allow such dates, and I have -- I
don't remember why! -- tried to use them.)

In addition, you would not be "retaining" any capability -- the systems
I know tend to turn negative dates into something on the order of:
	Sat Feb  5 01:28:16 2^A06
(This is -(60*60*24): the '^A' is, yes, a control-A.)
Any date after 31 Dec 1999 up to some value >> 2^31 loses everything
after the '2' in the year:  I think the second char of the year is
being converted to a control-@, or NUL character.

(Results from 4BSD and Ultrix on VAX and 680x0 processors.  I haven't
tried this on the s5/VAX.)
-- 

	Joe Yao		hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
			jsdy@hadron.COM (not yet domainised)

Volume-Number: Volume 6, Number 43

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/06/86)

From: campbell%maynard.UUCP@HARVISR.HARVARD.EDU (Larry Campbell)
Date: Fri, 5 Sep 86 01:51:09 EDT
Organization: The Boston Software Works, Inc.

>From: hadron!jsdy@seismo.UUCP (Joseph S. D. Yao)
>
>In addition, you would not be "retaining" any capability -- the systems
>I know tend to turn negative dates into something on the order of:
>	Sat Feb  5 01:28:16 2^A06
> ...
>(Results from 4BSD and Ultrix on VAX and 680x0 processors.  I haven't
>tried this on the s5/VAX.)

For what it's worth, I tried several interesting values on my VENIX 2.0
(V7-based) system.  It handles negative values "properly" (that is, it
prints reasonable dates prior to 1970);  for instance, 0xC0000000 yields
"1935 Dec 23 05:22:56".  And it also handles dates beyond 2000 correctly;
0x70000000 yields "2029 Jul 18 01:49:52".
-- 
Larry Campbell                             The Boston Software Works, Inc.
ARPA: campbell%maynard.uucp@harvard.ARPA   120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell     (617) 367-6846

[ Depends on what you call broken.

Another example where time values outside the currently supported
(or proposed) range would be useful:  some of us like to play with
genealogical software;  I have known ancestors back to the thirteenth
century and frequently work with data to the sixteenth century.
But time_t probably isn't the appropriate format to keep such dates,
considering Julian vs. Gregorian calendars, old and new style new years,
etc.  -mod ]

Volume-Number: Volume 6, Number 44

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/15/86)

From: cbosgd!cbosgd.ATT.COM!mark@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

std-unix@ut-sally.UUCP (Moderator, John Quarterman) (09/15/86)

From: mnetor!utzoo!dciem!msb@seismo.UUCP  (Mark Brader)
Date: Thu, 11 Sep 86 18:37:22 edt

> Another example where time values outside the currently supported
> (or proposed) range would be useful:  some of us like to play with
> genealogical software;  I have known ancestors back to the thirteenth
> century and frequently work with data to the sixteenth century.
> But time_t probably isn't the appropriate format to keep such dates,
> considering Julian vs. Gregorian calendars, old and new style new years,

I would say that time_t WOULD be the appropriate format, for PRECISELY
those reason, if the range was available.  To say otherwise is to say
that time_t is inappropriate for the way it's normally used because of
time zones and daylight and standard time.

[ Not precisely, since the form a date is recorded in may vary according
to not only present location but national origin of the recorder or of the
person whose date it is, since there are relatively odd formats (1617/18
is a common format, being used with a date between Jan 1 and Mar 15),
since many dates are incomplete (e.g., only year is known), and since
accuracy to the hour is very rare, not to even mention minutes or seconds.

Incidentally, the Mormon Church is coordinating the development of
something called GEDCOM (GEnealogical Data COMmunications), which is
a genealogical data interchange format.  (It looks rather like a network
presentation layer to me, even resembling XDR a bit.)  They must have
produced some standard for genealogical dates.  I believe I will write
off for a copy for myself.  The address (if anyone else is interested)
is probably

	Genealogical Department
	Ancestral File Operations Unit
	50 E. North Temple St.
	Salt Lake City, UT 84150

However, I suspect that general discussions on genealogy belong in
another newsgroup, so submissions to mod.std.unix related to genealogy
should probably be kept related to date formats or other implementation
issues.  -mod ]

While I'm writing I must correct the common assertion that time_t represents
a time in the UT (GMT) system.  It doesn't.  It represents a time in seconds
from a certain epoch.  The time in time_t form at the moment, for instance, is
526,841,748.  The corresponding time in UT is 4:55:48 pm.  Granted that
the latter is derived from the former by slightly simpler arithmetic than
is my local zone time, that doesn't mean that a time_t represents a time
in UT in particular.

I don't think this is of sufficient interest to post to mod.std.unix,
but you may post any or all if you wish.

Mark Brader, utzoo!dciem!msb
	If ... it seems easier to subvert UNIX systems than most other systems,
	the impression is a false one.  The subversion techniques are the same.
	It is just that it is often easier to write, install, and use programs
	on UNIX systems than on most other systems, and that is why the UNIX
	system was designed in the first place.
				-- Frederick T. Grampp & Robert H. Morris

Volume-Number: Volume 6, Number 48