On Sun, May 13, 2001 at 04:49:29PM -0700, Eric G. Miller wrote:
> > Comparing 7.1.1 against 7.0.*, I note that the resolution of "illegal"
> > times during a DST jump has changed, at least on my platform (HPUX 10.20).
> > 7.0.* resolves the time backwards whereas current sources resolve
> > forwards: "select timestamp('2001-04-01 02:02:02')" yields
> > 2001-04-01 01:02:02-05 in 7.0.2
> > 2001-04-01 03:02:02-04 in current
> > Since this is dependent on how the local mktime() library routine
> > reacts to "illegal" times, some platform-to-platform variation is to be
> > expected. Your example looks like mktime() must actually have some
> > internal state on your machine, causing its result to depend on what
> > it was asked previously :-(
>
> Yes, I think the timezone environment variable is being carried. I wrote
> a small test program, and the same weirdness happens. So, it's not
> specifically a PostgreSQL issue.
Follow-up:
I tested alway initializing the members of "struct tm" to INT_MAX the
performed the following operations:
1) strptime() to parse date/time string into struct tm
2) mktime() for time_t
3) localtime() for a struct tm again
4) strftime() for a string representation again
After doing that, the results become consistent regardless of the order
of the calls. You can't use "memset(theTime, 0, sizeof(struct tm))"
because when tm_isdst = 0 it say daylight savings time is false (which
you don't know yet from a string like '2001-04-01 02:30:30').
Example output from my test program:
BEFORE
ONE: 2001-04-01 01:30:30
TWO: 2001-04-01 02:30:30
THREE: 2001-04-01 03:30:30
AFTER
ONE: 2001-04-01 01:30:30-0800
TWO: 2001-04-01 01:30:30-0800
THREE: 2001-04-01 03:30:30-0700
REVERSED
THREE: 2001-04-01 03:30:30-0700
TWO: 2001-04-01 01:30:30-0800
ONE: 2001-04-01 01:30:30-0800
Without initializing the struct tm members to INT_MAX, the 2:30:30 time
would get interpreted as 1:30:30-0800 or 3:30:30-0700, and the 3:30:30
time would get returned as 4:30:30-0800 (which is right and wrong).
--
Eric G. Miller <egm2@jps.net>
