Incorrrect time display after daylight savings switch

I'm using postgresql under 4.3, if that matters.

I have seen some discussion about timezone problems with Drupal as a whole. See "timezone handling is still busted. Perhaps there are fixes in 4.4, but the Changelog doesn't mention a fix.

My timezone options are limited to GMT offsets, which doesn't consider the starting date of daylight savings time. Arizona, for example, doesn't use daylight savings time, though it uses Mountain Standard time during the winter.

This line in event.module under 4.4 concerns me:

$node->start = gmmktime($hour, $node->minute, 0, $node->month, $node->day, $node->year) - $GLOBALS['user']->timezone;

If I choose a date after daylight savings time changes, with my GMT - 8:00 setting, then 8 hours are added to the start time, even though the time zone will be GMT - 7:00 when the event actually occurs.

I suggest using standard *nix time zones, which are well thought out, rather than the direct GMT offsets which drupal currently uses. However, this change requires more than just event modifications.

I'm afraid that the fix may require a lot of work,

I was thinking the same thing. I suggest a field which combines time and date into one field. postgresql's documentation explains why, in a link I include below.

For postgresql, the best option may be

tswtz timestamp with time zone,

Each connection may have its own time zone. I'm not sure how to handle this within Drupal, but it should be doable. Here's a sample select statement, where tswtz is of type "timestamp with time zone". The right columns adds 5 days, but because of daylight savings time, the time part is off an hour, which is the way it should be.

wilma=# select tswtz, tswtz + '5 00:00:00' from fred;
tswtz | ?column?
-------------------------------+-------------------------------
2004-03-30 15:30:06.761742-08 | 2004-04-04 16:30:06.761742-07

PostgreSQL Date/Time documentation

Here's a quote from the documentation:

The type time with time zone is defined by the SQL standard, but the definition exhibits properties which lead to questionable usefulness. In most cases, a combination of date, time, timestamp without time zone, and timestamp with time zone should provide a complete range of date/time functionality required by any application.

Here's a quickie fix, which will work until timezones are really fixed. The fix is somewhat ugly, but less ugly than the current solution.

I have tested this in drupal-4.3.2

I added a function event_format_date, which is a slight modification of format_date. I placed the function in event.module. This function uses gmdate, rather than date. gmdate won't use the local timezone, unlike date. The timezone is added to timestamp, as it should be. For event, timestamp is the field start from the table event. Every instance of format_date in event.module is replaced with event_format_date. Maybe the function should be named gm_format_date. I'm tempted to remove date("Z") from this function, but this only gets called when timezone is null.

I also set timezone for user 0, which is the anonymous user.

update users set timezone=-28800 where uid = 0;

and set a default for timezone:

alter tables users alter timezone set default -28800;

Make sure that all users have timezone set. Perhaps you need:

update users set timezone=-28800 where timezone is null;

I am in Pacific time, which is -28800 in winter, and -25200 in summer. I have just set the time zone to winter time. This is ugly, but until there is a good timezone fix this will mostly work. Unfortunately, users may try to change their timezone to reflect daylight savings time; this will cause problems. I use winter time, because that makes start use UTC, which seems better.

You should choose your own favorite timezone, replacing -28800.

You may need to modify the start time of your events after this change.

Here is my patch against the 4.3 event.

My patch is the attachment to the previous post, which is probably obvious. However, my posting suggest that the patch follows the post.

Let me try a slightly different patch. There's only one line difference. I removed the date("Z") correction, because this was applied when timezone was set to 0, not just to null. So a person in UTC would be reset to using the local timezone, which is really not correct.

The new patch is attached.

Your solution is definitely better. I needed a quick solution, and didn't want to deviate too much from the standard release. I look forward to seeing your solution.