potential timezone handling bug [#72052]

I think there may be a bug in the timezone handling. I'm just looking at what is stored in the database and it doesn't look consistent with what I expect. I assume the value stored in the database is supposed to be the GMT time, right?

My server's timezone is set to EDT, mysql thinks it's in EDT and my date field is set to use the Site's Timezone, which is also set to US/Eastern.

Here are values from 9 example fields ...

database                display                 apparent TZ adjustment
2006-03-04T00:30:00     Mar 3 2006 07:30 pm     -5 hrs
2006-03-06T00:00:00     Mar 5 2006 07:00 pm     -5 hrs
2006-03-11T00:30:00     Mar 10 2006 07:30 pm    -5 hrs
2006-03-12T00:00:00     Mar 11 2006 07:00 pm    -5 hrs
2006-04-01T00:00:00     Mar 31 2006 07:00 pm    -5 hrs
2006-04-02T00:00:00     Apr 1 2006 07:00 pm     -5 hrs
2006-04-02T16:00:00     Apr 2 2006 11:00 am     -5 hrs
2006-04-08T14:30:00     Apr 8 2006 09:30 am     -5 hrs
2006-04-29T23:00:00     Apr 29 2006 07:00 pm    -4 hrs

I believe the last 3 should be -4 hours, since DST started on Apr 2nd this year.

Comments

Comment #1

KarenS CreditAttribution: KarenS commented 5 July 2006 at 11:34

Getting timezone handling right is my top priority right now, so this is my immediate focus. I'll get this working as soon as I can.

Comment #2

KarenS CreditAttribution: KarenS commented 5 July 2006 at 19:46

I've made a lot of changes to timezone handling in the latest cvs and tried to test that it was working correctly for a variety of situations. I'd like to get some others to test it now to be sure that values displayed in nodes and forms is correct for the selected timezone and that it is storing a gmt value in the database (unless no timezone handling is selected).

This will potentially affect (and hopefully fix) other issues, so I'm holding off on other changes until this can be tested.

Comment #3

RayZ CreditAttribution: RayZ commented 6 July 2006 at 03:06

I upgraded to the latest cvs, but I'm not seeing any changes in the example in my original post. In my example, I have a content type with an ISO date, a datestamp, and the event start/end dates. I didn't see any changes with the ISO date (I still think rows 7 and 8 are off by an hour).

The datestamp evidently did change. After updating the code all of them were off by several hours. Sorry, I manually corrected them without making a note of how much they changed.

Comment #4

KarenS CreditAttribution: KarenS commented 6 July 2006 at 10:36

Hmm, I'll have to keep looking. Maybe it's something in the timezone.inc file, or the way I've incorporated it...

Comment #5

RayZ CreditAttribution: RayZ commented 6 July 2006 at 15:27

Looks like the switch to DST is off by a week. For a date on April 8th the offset is -5 and for April 9th it is -4. Seems like the switch over is exactly 7 days late for US/Eastern.

Comment #6

RayZ CreditAttribution: RayZ commented 6 July 2006 at 15:30

Just to be clear, I'm referring to the offset I see between the displayed time and the time in the ISO date field in the database.

Comment #7

KarenS CreditAttribution: KarenS commented 6 July 2006 at 15:39

Aha! The timezone.inc file is calculating the time of the switch to dst using strtotime and the strtotime 'week' calculation for a date. That must be off by a week for some reason. I'll have to dig into the way that calculation is working...

Comment #8

KarenS CreditAttribution: KarenS commented 6 July 2006 at 16:24

Status:

Active

» Fixed

Found it. It is an error in the event_timezone.inc file. I fixed the included copy of that file and I'll post a fix to the event module. If you have event enabled, you'll need to fix your copy of that file, too, since that is used instead of my included file.

I tested it in both php 4 and php 5 on windows and in php4 on unix and had the same problem in all places - the dst start date is one week off and the dst end date is correct.

You need to change the section:

    case 15: // Northern America (where applicable)
      // start of DST  (where applicable) (first Sunday in April 2 am local time)
      $dststart = strtotime("1 week sunday GMT", strtotime("1 april $year GMT")) + 7200;
      // end of DST (where applicable) (last Sunday in October 2 am local time)
      $dstend = strtotime("-1 week sunday GMT", strtotime("1 november $year GMT")) + 7200;
      break;

to:

    case 15: // Northern America (where applicable)
      // start of DST  (where applicable) (first Sunday in April 2 am local time)
      $dststart = strtotime("0 week sunday GMT", strtotime("1 april $year GMT")) + 7200;
      // end of DST (where applicable) (last Sunday in October 2 am local time)
      $dstend = strtotime("-1 week sunday GMT", strtotime("1 november $year GMT")) + 7200;
      break;