> Another comment: I just peeked and, to be blunt, the time zone database
> looks like a mess.
Great! (Well, not great, but you know...). Let's clean it up. But we'll
need to get representation from the various regions covered to avoid
dropping useful fields.
> For example, there's CET (central
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Another comment: I just peeked and, to be blunt, the time zone database
> looks like a mess. For example, there's CET (central european time), but
> not CEST (central european summer time). Instead there's CETDST, which
> I've never heard used. Then
Thomas Lockhart writes:
> > ERROR: Bad timestamp external representation '1-1-2000 00:00:00 DST'
> > ERROR: Bad timestamp external representation '1-1-2000 00:00:00 ZP4'
> > ERROR: Bad timestamp external representation '1-1-2000 00:00:00 ZP5'
> > ERROR: Bad timestamp external representation '
Thomas Lockhart writes:
> Peter, will you be doing more work on configuration? If so, could we
> implement --enable-australian-zones (or something similar) which sets
> the internal USE_AUSTRALIAN_RULES parameter?
Will do.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e
(Cleaning up mail, and I don't see a reply to this...)
> Here are a few apparent discrepencies between pg7.0beta3 and the timezone
> documentation...
> 1) Unrecognized timezones claimed in the docs:
> ERROR: Bad timestamp external representation '1-1-2000 00:00:00 DST'
> ERROR: Bad timestamp e
