Subject: a brief history of time

From: [email-masked] (Mike Olson)
Date: Thu, 07 Nov 91 15:43:50 PST

over the past few months we've gotten bug reports on our time management
code from

	[email-masked]
	[email-masked]
	[email-masked]

and in fact it turns out that our code is pretty horrendous.  here are
a few known bugs that i have verified to exist this afternoon:

	+  abstimeout prints the name of the time zone you're in, but
	   if you supply it to abstimein, you get an error.  that is,
	   the time code can't parse the strings it produces.

	+  if you don't happen to be in the north american pacific time
	   zone, then the gmt calculations we do will be wrong for you
	   (in unpredictable ways, as far as i can tell; this is hard
	   for me to do extensive testing on).

	+  if you specify a time that happens to fall during daylight
	   savings time in your local time zone, we will add one hour
	   to it for you, at no additional cost.

	+  if you enter the time "", it is printed as "epoch", but it
	   does not equal the time "epoch".  the time input and output
	   functions disagree about what time zero means.

	+  there is a black hole at the unix epoch (jan 1 00:00:00 1970 gmt).
	   you can't name that time.  there is absolutely no reason for
	   this.

i have patched the current development tree to get rid of the black hole,
and to make the parsing of invalid times (such as ""::abstime) more rational.
however, dst rules are more than i want to bite into, since they're set by
legislatures, not logic.

it occurs to me that someone must have solved this problem before, and that
there must be a freeware solution in c somewhere out there.  if you know
of such a package and could let us know about it, we'd really appreciate
it.  failing that, our next release will at least get rid of the black
hole and the random behavior of ""::abstime.

					mike olson
					postgres research group
					uc berkeley
					[email-masked]