Обсуждение: 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>
Вложения
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