From: | "Sander Steffann" <s(dot)steffann(at)computel(dot)nl> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Anyone using "POSIX" time zone offset capability? |
Date: | 2006-10-17 12:23:24 |
Message-ID: | 00cd01c6f1e7$0e68b3c0$64c8a8c0@balefirehome |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Hi,
> The POSIX timezone notation as understood by the zic code includes
> the possibility of
>
> zoneabbrev[+-]hh[:mm[:ss]]
>
> but the meaning is that hh:mm:ss *is* the offset from GMT, and
> zoneabbrev is being defined as the abbreviation for that offset.
> What the datetime.c code is doing is trying to find the zoneabbrev
> in a built-in timezone table, and then adding the two together.
> This is simply wacko.
I think that if anyone has ever tried to use this notation they would have
noticed this misinterpretation of the specs.
> Given where the code stands now, I think the best solution is to
> rip out DecodePosixTimezone and instead pass the syntax off to the
> zic code (which can handle it via tzparse()). Since the datetime
> input parser is ultimately only interested in the GMT offset value,
> this would mean that the zoneabbrev part would become a noise word.
Sounds like a good idea to me.
Sander
From | Date | Subject | |
---|---|---|---|
Next Message | Shane Ambler | 2006-10-17 12:37:46 | Re: ERRORDATA_STACK_SIZE exceeded |
Previous Message | Stefan Sassenberg | 2006-10-17 11:47:48 | Re: ERRORDATA_STACK_SIZE exceeded |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-17 13:23:25 | Re: [HACKERS] Anyone using "POSIX" time zone offset capability? |
Previous Message | Hannu Krosing | 2006-10-17 09:59:10 | Re: Is python 2.5 supported? |