PostgreSQL requires time zones to be in an abbreviated format described on http://www.postgresql.org/docs/8.0/static/datetime-keywords.html#DATETIM...

The only place you can use anything other than those timezone abbreviations is when setting the time zone via SET time_zone = 'timezone'

The attached patch provides a new API which will look up the proper abbreviation via a LEFT JOIN, which must be added to the query by the caller, and removes mandatory conversion for UTC dates by setting the session's time zone to UTC for querying, so all queried dates are by default in UTC; This can be done without server timezone support.

An alternative solution is to convert all timezone fields and queries to use PostgreSQL abbreviations when PostgreSQL is in use, but this will make the database incompatible with MySQL, and vice versa, should the user want to migrate the database at a later date. The advantage is that it would not require extra joins, thus providing an API that is simpler to use, and more efficient queries once the timezones are converted.

The new API is 100% compatible with the old one when using MySQL, and is not tested with PostgreSQL since I do not currently have a PostgreSQL database set up. Timezone conversion will not work with PostgreSQL unless you adhere to the new API, and add the LEFT JOIN to the query.

No changes are made to actually use the new API in this patch, since there is some confusion as to whether times need converted from UTC at all for most queries.

CommentFileSizeAuthor
date-new-sql-API.diff16.22 KBChrisRL
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ChrisRL’s picture

Status: Active » Needs work
ChrisRL’s picture

It gets worse, unfortunately - Apparently the PostgreSQL abbreviated "timezones" are just aliases for fixed offsets that don't take DST/Summer Time in to account, so we may end up having to filter the results (Drop the entry with the wrong DST). Not pretty. The current code will at least do something (assuming I've got no bugs in it - and given that I haven't tested it in pgsql, bugs are likely), but the results will be duplicated for time zones with DST/Summer Time, one with the wrong time and one with the right one.

KarenS’s picture

Status: Needs work » Fixed

Based on this and the problems noted at http://drupal.org/node/218479, it appears we cannot count on being able to do timezone conversion in the database in any reliable manner, so I am rolling the Date and Calendar modules back to the code they used to use that uses offsets instead of timezone names.

I still need to roll forward and re-apply patches that came after this change, and then see what other adjustments are needed.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.