From: | "Eric G(dot) Miller" <egm2(at)jps(dot)net> |
---|---|
To: | PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Cc: | "Eric G(dot) Miller" <egm2(at)jps(dot)net> |
Subject: | Re: Bug with timestamp !!! |
Date: | 2001-05-14 00:36:29 |
Message-ID: | 20010513173629.B307@calico.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-bugs pgsql-general |
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(at)jps(dot)net>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-14 01:31:40 | Re: Bug with timestamp !!! |
Previous Message | Eric G. Miller | 2001-05-13 23:49:29 | Re: Bug with timestamp !!! |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-14 01:31:40 | Re: Bug with timestamp !!! |
Previous Message | Eric G. Miller | 2001-05-13 23:49:29 | Re: Bug with timestamp !!! |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-14 01:31:40 | Re: Bug with timestamp !!! |
Previous Message | Eric G. Miller | 2001-05-13 23:49:29 | Re: Bug with timestamp !!! |