
Under Win32, localtime returns NULL for dates pre 1970.

A number of places in the code fail to check from a NULL return from
localtime, with none seemingly more problematic than those calls within
DetermineLocalTimeZone, which causes SEGVs in a number of tests (which
clearly pass pre 1970 dates to this function).

If we want to support pre-1970 dates, which I imagine we do, then this
function requires some serious rework under Win32. If we don't, then I'm
guessing we can just drop in some error checking for a NULL return from
localtime (as I've done on my personal source base), and modify the tests
for Win32 accordingly.

Comments?

Cheers,
Claudio
--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>

Mon, 2 Feb 2004 16:55:37 +1100 
Claudio Natoli <claudio.natoli@memetrics.com>
Pre-1970 dates under Win32
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> Under Win32, localtime returns NULL for dates pre 1970.

Count on Microsloth to get it wrong :-(

> If we want to support pre-1970 dates, which I imagine we do, then this
> function requires some serious rework under Win32.

I think the long-term trend here is to implement our own timezone
library and stop relying on libc for this service.  While M$ seems
to have achieved a new low, there are lots of crummy timezone
implementations out there.  I'd not recommend spending a lot of time
on patching the existing code.  Erroring out rather than crashing is
probably sufficient.

			regards, tom lane

Mon, 02 Feb 2004 01:57:15 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Pre-1970 dates under Win32 
On Mon, Feb 02, 2004 at 01:57:15AM -0500, Tom Lane wrote:
> Claudio Natoli <claudio.natoli@memetrics.com> writes:
> > Under Win32, localtime returns NULL for dates pre 1970.
> 
> Count on Microsloth to get it wrong :-(

I had a discussion about time_t some weeks ago.  There is nothing
in the standard that says time_t must be a signed, all it says is
that (time_t)(-1) represents an invalid value.

There are other OS's that have an unsigned time_t.


Kurt


Mon, 2 Feb 2004 08:37:37 +0100
Kurt Roeckx <Q@ping.be>
Re: [HACKERS] Pre-1970 dates under Win32
Kurt Roeckx <Q@ping.be> writes:
> I had a discussion about time_t some weeks ago.  There is nothing
> in the standard that says time_t must be a signed, all it says is
> that (time_t)(-1) represents an invalid value.

Don't get me started :-(

No sane person (certainly no one born before 1970) would think that
there is no need to represent pre-1970 dates.  Also, anyone who harbors
ambitions of still being around 40 years from now will realize that the
current 32-bit range of time_t is inadequate.  Fortunately, Moore's law
will save us.  We can simply move to a 64-bit, signed representation of
time_t, maintaining the 1970 origin for compatibility's sake.  That will
hold us till, if not the heat death of the universe, at least an epoch
where no one will blink an eye at 128-bit time_t.  It will also provide
a standardized representation for pre-1901 times, something we lack now.

Given that that's surely where we'll be in a few years, I can see no
reason to abandon the past and pretend that time_t should be unsigned.

The special case for -1 is certainly a wart, but it's not a flaw in the
datatype definition, just a bug in the APIs of a few libc routines that
couldn't be bothered with providing a separate error return value.
These routines could be deprecated, the same way the ones with
non-reentrant APIs have been deprecated.

AFAIK all the old-line Unix implementations consider time_t signed.
I quote for example the HPUX man page for mktime():

             If the calendar time cannot be represented, the
             function returns the value (time_t)-1 and sets errno
             to ERANGE.  Note the value (time_t)-1 also
             corresponds to the time 23:59:59 on Dec 31, 1969
             (plus or minus time zone and Daylight Saving Time
             adjustments).  Thus it is necessary to check both
             the return value and errno to reliably detect an
             error condition.

In any case, making the type unsigned hardly makes the -1 special case
go away, it simply moves it out to 2100-something.

			regards, tom lane

Mon, 02 Feb 2004 03:08:05 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Pre-1970 dates under Win32 