Document rule set scheduling in UTC

I'm encountering the same problem: Here in Chicago, if you enter, say, September 15, 11:00 am, in a CCK date field that's used in a scheduled rule, when you look at the scheduled tasks overview, the displayed time is September 15, 6 AM--exactly -5 hours from GMT.) So, clearly, time isn't being adjusted locally when it's pulled out through views.

I applied the patches you mentioned above, but I didn't have any luck either. The good news is that the time is being saved correctly in the rules_scheduler table, so it will probably still execute at the desired time.

It looks like one of the patches creates class rules_scheduler_views_handler_datetime. I don't think this is being called correctly. Will post something soon.

I could be wrong but I think I read somewhere the Publish Date/Time has to be in UTC/GMT. Doing this works for me but obviously relies on the end user getting it right so is not fullproof.

Yes, the db table I'm looking at is the rules_scheduler table. It appears to me that the time entered when you create the content is being saved into that table correctly. You are right, though: Rules is not executing it at the proper time. It seems pretty clear that the datetime isn't being localized correctly. It must be getting turned into a straight GMT time during execution. Hmmmm...

I'm having the same problem. I have my date field set with no time zone conversion so that what the user enters is what is stored in the database, but when a schedule is created using this date field it's always adding on 1 hour. Does any one know how to fix this?

same here. i have my date module configured and cck date fields working but rules gets executed in gmt, not time i set. date() functions display gmt although php is set for correct timezone.

Example in handbook tells "Rules Scheduler saves dates in GMT/UTC internally, but displays them in your timezone setting".

I am more interested in when scheduler triggers ruleset - in gmt as saved internally or in my timezone, saved in date module settings.

This is actually a very strange issue. We have the same problems here as mentioned above. If you will look inside the hook_cron of rules_scheduler module you will see:

$result = db_query_range("SELECT * FROM {rules_scheduler} WHERE date < '%s'", gmdate('Y-m-d H:i:s'), 0, 30);

This query is a problem. It takes the date in timezone you entered (which can be other then GMT/UTC) and checks if it is less then current GMT/UTC date of the server. See what i mean?

I will test it more and report here after.

For now i'm setting this issue state to critical, because it breaks schedule functionality in some cases.

Any progress with this? To fix the error i hacked rules_scheduler module replacing gmdate() with date() in hook_cron(). You need more information? Usecases?

subscribing

I just noticed this problem as well just now.

looking in the database table (rules_scheduler) it looks like rules that are scheduled with Tutorial 2: Publish content exactly 24 hours after it was created get saved in the database in UTC while the rule scheduled using Tutorial 3: Publish content based on a CCK date field get saved into the database using the same timezone as the user/site.

I feel that the fix to the problem should be to save the time for the scheduled event in the database as UTC, instead of the user's timezone.

I don't think there is a bug, the action just expects the date to be in UTC. Well, the token of the date field used in tutorial 3 might not be in UTC though.

So the tutorial probably could be improved, or at least should mention that issue. Maybe one can configure the date field so that it internally store the time in UTC and thus provides a token in UTC?

Has anyone managed to find a solution for this as it's starting to do my head in.

If I set my Default Time Zone to Europe/London my site displays the correct time, I have my CCK field set to No Time Zone Conversion (by I have tried it on UTC as well and get the same problem), but Rules Scheduler is adding an hour.

If I set my Default Time Zone to UTC the time on my site is wrong.

Is there a way of Rules just ignoring timezones, I just want to rule to be scheduled at the time I've requested not for it to covert it based on time zones.

I just noticed that the values stored in the database are correct, it's what is displayed in the schedule view that is 1 hour ahead. Does this mean that my rules will happen at the correct time even though they are displaying incorrectly?

If anyone's interested (marcus178?) I've found a way to circumvent this effect.

Instead of using a token to set a date, I use PHP (with PHP filter activated), and set the date with something like this:
echo $node->field_my_date[0]['value'] + variable_get('date_default_timezone', 'UTC');

(In reality I was using '0' instead of 'UTC', but I just found 'UTC' in another context and it seems more reasonable.)
If you have user configured timezones I guess you might have to use a more complex statement, perhaps involving conditions.

Is this a bug or not?
It would be nice if Rules Scheduler checked for timezone configurations for CCK fields and compensated for this -- but I don't really see how that could be made in any consistent way. There aren't necessarily any CCK fields involved when you set evaluation time in Rules Scheduler. Theoretically you could check for any CCK date/time tokens and compensate for the field's configuration, but that would quickly turn into an ugly task.

A neater solution would be to (1) state clearly that the evaluation time should be set in UTC, regardless of the timezone configurations, and (2) include a Token for date/time fields that holds the time in UTC (which could be useful in other cases as well).

Those are my cents of thought!
//Johan Falk, NodeOne, Sweden

EDIT: Feature request for UTC normalized date token now submitted! http://drupal.org/node/795076

Here's a suggestion for an additional text in the information below the field for entering an evaluation time for scheduling.

Format: 2010-05-11 18:26:38 or other values in GMT known by the PHP strtotime() function like "+1 day". Please note that any time entered will be interpreted as timezone neutral -- you will have to compensate for any timezone configurations.

An additional patch changes the label for the field to make it explicit that it doesn't take timezones into account.

Scheduled evaluation date (timezone neutral)

(This might be my very first patch to a Drupal project!)

//Johan Falk, NodeOne, Sweden

Thanks for this but I found this didn't work for me either but the following did

<?php echo format_date($node->field_event_date[0]['value'],'custom','y-m-d 17:55:00',0); ?>

I had to format the date as I required it to be scheduled at a specific time.

@Itangalo: Congratulations on posting your first patch! Here are couple of tips: When you post your patches, update the status to 'needs review;' this will also trigger the test bot to automatically run them through simpletest if the module uses tests. For them to be reviewed properly and to make it easier for other developers, create the patch from the module's root directory. The general guide can be found at http://drupal.org/patch/create

#17: timezones.patch queued for re-testing.

#17: timezonelabel.patch queued for re-testing.

@opensanta: Thanks! Looking forward to learn and improve. :-)

Ok, here goes another try!
Learning every day.

(I noticed that some translations will have to be updated if this patch goes through, but I didn't consider it a work that should be included here.)

Hoo hay what a great day!
Me patches passed the first test!

hehe, congrats.. :) You don't need two patches though, just roll it into one.

@patch:
I'm not aware of any "timezone neutral" terminology? This is a common phrase? At least for me not ;) Perhaps just say "Date in UTC" ?

I spent quite a bit of time debugging this so I'll add some details to save everyone a bit of time.

1) Configure a CCK date field. I configured "Time zone handling" to User's time zone. In my case, I'm using repeating dates but the array in the $node ends up looking like this. Note that the [value] is actually stored in UTC/GMT time by the date module.

            [0] => Array
                (
                    [value] => 2011-01-23T05:40:00
                    [rrule] => RRULE:FREQ=DAILY;INTERVAL=1;UNTIL=20110211T155959Z;WKST=SU
                    [timezone] => America/Los_Angeles
                    [timezone_db] => UTC
                    [date_type] => date
                )

2) Create your trigger rule. In my case, I trigger upon node update, and then I set up actions. The actions is where I needed the work.

Action #1:
Rules -> Add a new date variable
date: echo $node->field_date[0]['value'];
Label: GMT date
Machine readable variable name: gmtdate
Weight: 0

Note that in the above, I set up a variable that calls into $node, which was passed in via a rules argument. You should see this if you expand the "PHP Evaluation" menu right under the tokens. If it's not there you don't have an argument passed in. The field_date is the name of my CCK date field.

Action #2:
Rule Scheduler -> Schedule MyRuleset (assuming your ruleset was already created)
Identifier: node [node:nid]
Scheduled evaluation date: echo $gmtdate;
Weight: 1

What this does is pulls the date out of the CCK field in GMT/UTC time, and then schedules it using that date instead of whatever other timezone conversion would take place. Since the SQL query against rules_scheduler is using gmdate(), this makes it so that the rules fire off at the correct time.

I was having the same issue, scheduling the publish and unpublish date of content. I'm in the Pacific time zone, so content was being published/unpublished 8 hours earlier than it was set.

So I went to the triggered rule and, in the action, under "Scheduled evaluation date," I changed [node:field_expiration-datetime] to [node:field_expiration-datetime] +8 hours

But that changed the scheduled date to 8 hours ahead of PST time. So I changed it to [node:field_expiration-datetime] +0 hours and, then, the scheduling was correct. Weird. But it worked.

#31 works for me, thanks. Nice and simple. Pacific/Auckland is the server timezone, the CCK field is set to use the user's timezone. I'll have to test with a user in another timezone.

Using the token [node:date_field_name-value] also appears to correctly schedule events.

Using the token [node:date_field_timestamp] also appears to correctly schedule events.

Please compile the information here into a documentation page.