Thread

Why not release a separate patch to “fix” the DST issue for those interested in an immediate resolution?

Or, what about putting a fix into this release which at least makes DST right for any _new_ sites constructed.

That way, new projects can move forwards, or anyone who is willing to make some manual corrections on a site that isn’t too filled up.

The overall revise-what-1.6-did sounds tricky and time-consuming, and can be a patch or even possibly an add-on at later date?

In any case, good on you for first moves to greater transparency, which are understood.

Regards,
Clive

Toi toi!

And I would like to fourth the suggestion of a new global override to side-step the date issue for sites where backwards compatibility isn’t an issue, perhaps that’s something that can be accomplished in a matter of weeks, versus a complete solution that still feels a ways off?

But seriously, great post, the detail really helps.

Cheers,
Matt

So am I correct in assuming most of our time problems will magically seem fixed when DST ends on November 7th? That’s probably a logical reason to opt for the more meticulous fix.

But in all honesty, if the “correct” fix was available today, I would use it even if it bumped all my times off an hour. I’ve already had to deal with that after server moves, so once more wouldn’t kill me.

Just wanted to +1 the request to have some kind of global “disable anything to do with DST” option that would cause all dates to be saved and handled as per the current server time.

This would be extremely useful for new sites that don’t need localizing and could presumably be delivered much quicker than what - I presume - will end up as a complex fork of the upgrade procedure.

Just a quick side question…
Is this a straight forward update / upgrade? Or is there likely to be structural changes that might affect 3rd part extensions, etc?

Thank you Derek and the rest of Ellislab team. This is the type of discussion we want to be in. Btw, are we going to have the updated (in your hotfix) cp.publish.js added as well?

Sorry, which are you referring to, Cem?

Why not release a separate patch to “fix” the DST issue for those interested in an immediate resolution?

Do you mean something that will work for people who do not use either of those two settings at all?  If so, then if you open /system/expressionengine/libraries/Localize, in the convert_human_date_to_gmt() method you should be able to get around the issue by commenting out the following code:

if (date("I", $this->now))
{
    if ( ! date("I", $time))
    {
        $time -= 3600;            
    }
}
else
{
    if (date("I", $time))
    {
        $time += 3600;            
    }
}