Обсуждение: 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: > 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