More Time Zone fun
I'm making (slow) progress in my timezone system, and I just noticed
this little behavioral nugget, which surely is a bug. In the system view
pg_timezone_names is a few timezones that use leap seconds. An example
which I tested is Asia/Riyadh87. When I attempt to SET TIME ZONE using
this timezone, I get this:
ERROR: time zone "Asia/Riyadh87" appears to use leap seconds DETAIL:
PostgreSQL does not support leap seconds.
Surely it's a bug to have timezones in the list that result in errors
being thrown? Also, is there a reason that PostgreSQL does not support
leap seconds?
Regards,
- Naz
Just to further note an oddity, apparently PostgreSQL in fact *does*
support leap seconds since 7.4 After scouring the manual for info on
this, I discovered on this page:
http://www.postgresql.org/docs/8.2/static/release-7-4.html
Tom added support for 60 second values in the seconds component of
TIME/TIMESTAMP/INTERVAL data types, which, as noted by the changelog, is
needed for support of leap seconds. So this error very well may be a
behavioral bug. Should I post this to -hackers or -bugs ?
- Naz.
Naz Gassiep wrote:
Show quoted text
I'm making (slow) progress in my timezone system, and I just noticed
this little behavioral nugget, which surely is a bug. In the system
view pg_timezone_names is a few timezones that use leap seconds. An
example which I tested is Asia/Riyadh87. When I attempt to SET TIME
ZONE using this timezone, I get this:ERROR: time zone "Asia/Riyadh87" appears to use leap seconds DETAIL:
PostgreSQL does not support leap seconds.Surely it's a bug to have timezones in the list that result in errors
being thrown? Also, is there a reason that PostgreSQL does not support
leap seconds?
Regards,
- Naz---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Naz Gassiep <naz@mira.net> writes:
ERROR: time zone "Asia/Riyadh87" appears to use leap seconds DETAIL:
PostgreSQL does not support leap seconds.
Surely it's a bug to have timezones in the list that result in errors
being thrown?
Perhaps, but weren't you the person complaining about how slow that view
is to read? If we actually opened each tzinfo file and looked for
leap-second data, it would likely be 10x to 100x slower yet.
Also, is there a reason that PostgreSQL does not support
leap seconds?
timestamp/interval arithmetic would be completely unworkable
... especially for future dates where the occurrence of leap seconds
cannot be predicted.
Some googling suggests that the whole concept of leap seconds is falling
out of favor with the people in charge of such things --- it's just as
bad as trying to predict what the politicians will do to daylight
savings time next year :-(
regards, tom lane