Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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 commentedGetting 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 commentedI'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 commentedI 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 commentedHmm, 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 commentedLooks 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 commentedJust 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 commentedAha! 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 commentedFound 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:
to:
Comment #9
RayZ CreditAttribution: RayZ commentedI confirm this appears to correct the problem I was seeing.
Comment #10
(not verified) CreditAttribution: commented