Hello. I've been using the Scheduler module for a few months now and it has worked fabulously. Just a couple of days ago the timezone I'm in (U.S. Eastern Time) changed so that the clocks are all set back by one hour. And now my scheduled posts are being published one hour earlier then they should be and the timestamp is incorrect.

Just to clarify since that description might be a little confusing:

I set all my scheduled posts to publish at 11:00 am every day and then when 11:00 am rolls around and cron runs, they get published and show timestamped at 11:00 am. But for the last couple of days (since the daylight savings time switch) they are being posted at 10:00 am BUT being timestamped as 11:00 am.

I've checked all of these things:

1. My server is set to the correct timezone settings

2. The "Admin > Date & Time" setting is correctly set to "America/New York"

3. My Drupal user account timezone setting is correctly set to "America/New York"

Thanks so much for any suggestions as to what to look into! This is a great module and I really appreciate the time that goes into it!

Files: 
CommentFileSizeAuthor
#9 dst.scheduler.module.patch716 bytesadr_p

Comments

Title:Schedules posts off by one hour right after Daylight Savings Time switchScheduled posts off by one hour right after Daylight Savings Time switch

Did you schedule your posts before the DST switch?

Yes, they were scheduled before the DST switch.

Status:Active» Closed (works as designed)

OK. This is a common misconception:

You scheduled a story for 11:00 EST-DST, because at the time you scheduled the story your site still ran on DST. But 11:00 EST-DST is the same as 10:00 EST. Times are always stored in a universal format, because drupal users may use different time zones. When times are entered they are converted into the universal format (UTC) before they are stored. When they are displayed they are converted to the time zone of the current user.

See it this way: The story was published at the right time. The time you entered was 11:00 EST-DST and it was published at 11:00 EST-DST. The problem is that you are now living in a different time zone (EST) in which that time is 10:00.

What to do about that?
If you schedule nodes across DST switch boundaries you need to enter the times shifted about the DST switch value. E.g. if you want a node to be published at 11:00 EST, but you still are on EST-DST you need to enter 12:00 (which becomes 11:00 after the switch).

It is really, really difficult to do that automatically, because your time zone is identified by a offset from UTC (e.g. +0500 for EST, +0600 for EST-DST). If scheduler looks up you time zone it does not know when your DST switch will happen or if at all (there are countries that do not switch to DST). Thats why scheduler does not know if it should adjust the value you entered to a DST switch. The only thing that we could do is providing the user with a time zone selector for all time fields. I don't think people would want that. Or maybe we could add a field to the users profile for the country she lives in. But it would still be very difficult, because the whole DST issue is very complicated. If I would know an easy way around the whole issue I would happily implement it, because my own client run into this problem every DST switch...

Hmm... Interesting. Thanks so much for the explanation. I think I'm all set and this issue can be closed.

As for suggestions as to what to do about this in the module code... I'm going to roll it around in the back of my mind and see if I come up with any ideas. It sounds like you've done a lot of thinking about this and it does seem like a complicated issue. Thanks for the response here and for all the help you give with this module. It's much appreciated.

Thanks for reporting back.

There is a way to do this with custom code. I am using this function:

function get_time_offset($mydate)
{
$basedate = strtotime($mydate);
$dayname = date("l",$basedate);
$daynum = date("d",$basedate);
$monthnum = date("m",$basedate);
$yearnum = date("Y",$basedate);
if($monthnum>10 || $monthnum<3)
$ora = 2*3600;
else if($monthnum<10 && $monthnum>3)
$ora = 3*3600;
else if($monthnum==3)
{
if($daynum<25)
$ora = 2*3600;
else
{
if(($dayname=="Saturday" && $daynum<31) || ($dayname=="Friday" && $daynum<30) || ($dayname=="Thursday" && $daynum<29) || ($dayname=="Wednesday" && $daynum<28) || ($dayname=="Tuesday" && $daynum<27) || ($dayname=="Monday" && $daynum<26) || ($dayname=="Sunday"))
$ora = 2*3600;
else
$ora = 3*3600;
}
}
else if($monthnum==10)
{
if($daynum<25)
$ora = 3*3600;
else
{
if(($dayname=="Saturday" && $daynum<31) || ($dayname=="Friday" && $daynum<30) || ($dayname=="Thursday" && $daynum<29) || ($dayname=="Wednesday" && $daynum<28) || ($dayname=="Tuesday" && $daynum<27) || ($dayname=="Monday" && $daynum<26) || ($dayname=="Sunday"))
$ora = 3*3600;
else
$ora = 2*3600;
}
}
return $ora;
}

This will give me an offset of either 2 or 3 hours, depending on the timezone (winter or summer) of the date that I provide to the function. So if it is a winter date, I will get 7200 and if it is a summer date I will get 10800. You can easily adjust the offsets to suit your needs.

I assume that the day time shifts on the last Sunday of March and last Sunday of October. I know that the time is supposed to change at 4:00 am on that Sunday, but for simplicity reasons I shift the date as soon as Sunday begins (4 hours earlier than it should).

Note that you have to work with the the date stored in the database and NOT the current date. I think it is easy to understand why.

I assume that the day time shifts on the last Sunday of March and last Sunday of October

There you have it. This may work for your site, your time zone(s) and your Country/State/County but may be very different for all other users of scheduler. This is actually something that would have to be a central/core feature (as all Date/Time handling). There have been neverending arguments about this in the community. I don't know if there will be better DST support in D7...

Category:support» feature
Status:Closed (works as designed)» Needs review
StatusFileSize
new716 bytes

There is a module named "Daylight saving time" (http://drupal.org/project/dst) that solved my timezone/dst issues. However you must patch scheduler in order to have it cooperate with that module. I've attached the patch below.

Without the patch - if dst is enabled - after saving a node you'll get different publish_on and unpublish_on values when you get back to the node edit form (even that the values are proper in db).

Please don't hesitate to test it and reply.

I'm author of dst module.
Make double o my comment(http://drupal.org/node/1189080#comment-4631540) here

good notice but I think your patch is not enough there.
gmmktime is more correct there becaus of mktime "as is" depends from local timezone. but also is not correct at all.. Module must understand timezone value to make correction for input.

the better way to correctly shedule dates and give correct input of sheduled time - use http://ru.php.net/strftime while date input as it's used in node edit pages.

Anyway time is stored in timestamp. See node edit foms as they give dates there. There is most correct variant.

@Ilya1st
Could you please post a patch for Scheduler?

@adr_p
hmmmmmmmmm
that was my mistake. yes. I've forgotten than dst makes date_default_timezone_set() on hook init.
if dst is used that would be correct usage of mktime

but I recommend use strftime instead as it was made in node module in node edit form.
I will not provide patch.
Your patch is correct too. Sorry.

Look very useful. I will checkout dst and test the patch when I get around to it...

BTW: How is this handled in D7? According to the dst description D7 has this built in. Does it set the configuration variable 'dst_used' too?

Version:6.x-1.6» 7.x-1.x-dev

I've hit this on D7 too. I manually adjusted the schedule by an hour, but it'd be nice to have a real fix.

Version:7.x-1.x-dev» 6.x-1.x-dev
Status:Needs review» Needs work

The Daylight Saving Time module is not ported to D7, so the patch cannot be applied to D7. Another solution is not easy (see Eric's explanation from #4). We need support from core or a third-party module to fix this in D7 and higher.

Setting back to D6 for the moment. The patch also needs work: it needs to be documented and rerolled, it is not using the current patch format.