From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Brandon Aiken" <BAiken(at)winemantech(dot)com> |
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 01:14:19 |
Message-ID: | 8445.1161047659@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
I wrote:
> ... I'm not entirely convinced that it really is a POSIX-sanctioned
> notation, either --- the POSIX syntax the zic code knows about is
> different.
Actually, I take that back: it is a subset of the same notation, but
the datetime.c code is misinterpreting the spec!
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.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Douglas McNaught | 2006-10-17 01:17:50 | Re: Permission problem with create tablespace |
Previous Message | Andras Simon | 2006-10-17 01:06:49 | Permission problem with create tablespace |
From | Date | Subject | |
---|---|---|---|
Next Message | Chuck McDevitt | 2006-10-17 04:57:00 | Re: Upgrading a database dump/restore |
Previous Message | Euler Taveira de Oliveira | 2006-10-17 00:47:17 | Brazilian FAQ update |