Civimail "send immediate" uses user's local time and not server time

[Dennis Gray]

Seems this topic has been discussed several times. IMO, when a mailing is submitted to be processed "immediately", the server's time should be used and not the user's local time. Likewise, the user's local time should be translated into the server's time for scheduled mails.

I've been doing some testing from Australia. The server is in Houston. When the mail is submitted, it gets submitted with the user's local time and is not processed until the server catches up.

[Dennis Gray]

From the user's point of view, "immediate" does mean his/her local time but users are not aware that there is a server in the background set to another time. In Australia's case, that time is in the past.

[Andrew Perry]

The time a mail is sent should be in the mail headers relative to UTC, so on the receiver's end it would be displayed with appropriate adjustment for the receiver's UTC offset - is that not happening?

[Dennis Gray]

This is about the time the mail is scheduled from the Civimail sender's point of view, not what's in the recipients header. Now it is 0800 Sydney time 6 June. Server in Houston is now 1600 5 June. If I schedule a mailing "send immediate" the server won't process it for another 16 hours when it is 0800 6 June in Houston.

[Donald Lobo]

One easier solution for now, is to let your server in Houston set the local timezone to Sydney and that should solve the issue. This can be done via the hook_civicrm_config, with something like:

    // set the timezone                                                                                                                     
    date_default_timezone_set('America/Los_Angeles');

The longer term solution would be for CiviCRM to be "timezone aware" with regard to all time operations. This is a bit more involved, and ideally should be "user specific" and all times in the DB are stored as UTC (and then converted as needed). Would be great if the DA developers could look into this issue and potentially fix it

lobo

[Dennis Gray]

We have several dozen "Civimail administrators" spread throughout the world so it is not only relevant to Sydney.

Unfortunately, our organisation does not have the budget to pick up the cost of the development that would be required, as you describe in your second paragraph. The best I could do would be to publish a use case or two for what I have in mind and maybe someone else with a similar problem would be interested in it.

[cesy]

If you could publish the use cases, I'd be interested - the org I work with also has administrators around the world.

[Dennis Gray]

Sorry, I haven't gotten back to this as there were other priorities. I did want to mention that I just sent out a mass mailing using CiviCRM 1.9 and used the "send immediately" option. It seems like the time on the server was used, rather than my local time so my mail was processed as soon as the chron job kicked off.

I suspect some change was made in the code that altered the behaviour in 3.x

Still investigating