Daylight Savings Time issue

Subscribing... was just about to post this issue. But in my case, all dates updated beyond March 8th are getting shifted back by 2 hours. Then when the date is edited, again it's shifted back one hour.

Managed to downgrade to 6.x-2.0-rc6, and incorrect DST behaviour is the same. Since dates are not functioning correctly past March 8th, I think it's fair to upgrade this to critical...

Hmm, it appears that issue was occurring only when the "use PHP's default timezone" option was enabled for the PHP4 module. Sorry, turns out my issue is unrelated to the issue originally posted. Will post a separate issue.

There are two different issues here, one for problems when using Date PHP4 and one for problems using the native date handling for PHP 5.2 and later. I have confirmed that there are problems and am working on them. What I have so far:

1) The Date PHP4 code gets the offset wrong on the day that daylight savings time changes -- it uses the old offset instead of the new offset when computing the value stored in the database. That error gets compounded when you edit the node as it displays the wrong value for the stored value. It seems to work correctly again after that day. I'm working on getting a fix for that problem.

2) The PHP 5.2 code gets the offset right but makes the wrong adjustment to the date value, but only during the time period of the change, from 2am to 3am. All other times it appears to work correctly. This actually appears to be a PHP bug, I'm trying to figure out a workaround.

3) So far I can't replicate a problem with *all* dates past March 8, just problems on that date. But if there are, that is certainly related to this problem.

And using the PHP4 option to use default timezone handling introduces yet another way it can get broken :( But I'm trying to find a workaround for all of these issues.

I've posted some fixes that work for me to get PHP4 handling the dst changes correctly. I'm hoping that will take care of that issue.

The PHP 5.2 issue looks like a 'by design' issue. If daylight savings time changes at 2:00 am on March 8, there actually is no such time as 2:00 am. There is 1:59 and the next minute is 3:00 am. If you try to create a time anytime between 2:00 am and 2:59 am PHP 'helpfully' tries to fix it by turning it into 3:00-3:59 am. IMO it should display an error instead, but it doesn't. That behavior is true for other invalid dates, like February 30, which gets automagically converted to March 1 or March 2 (depending on whether there is a February 29).

Because 2:00 am is an invalid time, the way it is handled gets garbled both when it is saved and when it is displayed, so you can go around and around by creating an invalid date, saving it, re-displaying it to see something else, saving that, etc.

I see no way I can alter the code to intervene and create an error where PHP creates a valid date. I suppose I could do some checking in the node form validation to see if your post created an invalid date and display an error if it does, but that's going to add a lot of overhead to the code. And that's if I can even figure out a way to identify those situations, which I can't.

So I don't know what else I can do here. It's not really fixed, but it's not 'active' either.

Please note that the Date PHP4 module included in Date 6.x-2.1 still shows above mentioned issues. In particular, March 28 is being shown twice in Calendar view (using the CET timezone).

Is there a way to disable all this timezone processing? Alas, setting Date PHP4's default handling to TRUE breaks Calendar completely (no dates shown at all).

subscribing, I have March 28th shown twice too, and events on Sun March 29th not showing at all :(

I did try the previous posters suggestion about altering Date PHP4's default handling to TRUE - it DID NOT break my calendar, it made no change whatsoever, still 2 x Mar 28th's showing, all other events showing fine

I realise this probably isn't urgent especially if you have no weekend Events, but nearly all our events (football matches) take place on a Sunday, so it fairly much scuppered last weekends schedule display!

The one thing you might try is to get at the transition data from the Olson tables. PHP 5.2 has the functions for this:

$tz_name = 'America/Los_Angeles';
$tz = timezone_open($tz_name);
$transitions = timezone_transitions_get($tz);
print_r($transitions);

Typical transition record look like this:

    [127] => Array
        (
            [ts] => 1236506400
            [time] => 2009-03-08T10:00:00+0000
            [offset] => -25200
            [isdst] => 1
            [abbr] => PDT
        )

    [128] => Array
        (
            [ts] => 1257066000
            [time] => 2009-11-01T09:00:00+0000
            [offset] => -28800
            [isdst] => 
            [abbr] => PST
        )

They're in order, so you could do a binary search in 5.2 (5.3 lets you get a range).

That's no answer to your objection on the grounds of overhead, since I'd hate to carry around this mofo if I didn't need to. Perhaps the solution is to wrap your equivalent of timezone_open() into something that caches the transition table, and have it test for the "fence poll" values.

DST is fun, fun, fun, ain't it?

This issue has been inactive since 2009.
2010 saw daylight savings time go into effect and there did not seem to be much issue.
That might be because people upped to php5.2 or just worked around the issues with various time zone conversion options.
Or maybe we really did get this fixed (I sort of doubt it, especially for PHP4)

So, I am just going to mark this as closed now.

Here are a bunch of related issues with fixes & workarounds if you encounter this:
#369020: "Every First Saturday" skips Feb, March
#673178: March 28 2010 is not showing
#657832: May 1st 2010 events not showing up on calendar
#537910: March 2010 doesn't exist on my calendar.
#419836: 29th of Mars replaced by 28th of March in all kind of displays
#673178: March 28 2010 is not showing
#564506: Date Browser doesn't like March 2010