Thread: Pre-1970 dates under Win32
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>
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
> I'd not recommend spending a lot of time on patching the existing code. > Erroring out rather than crashing is probably sufficient. Agreed. This fixes the ones bugging me now. I'll provide others as I trip over them. [Note: this'll mean some changes to the tests for Win32] 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>
Attachment
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
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