Sites provisioned via Aegir do not have a default timezone set. For the purposes of automation, it seems worthwhile to me to have them default to the system timezone's offset rather than be null altogether.

Patch attached gets the offset from php's date() function and sets the date_default_timezone with it via variable_set. I'm not sure if this is the advised way to handle this sort of thing, but it works..

(note I am patching install_6.inc here, but for the purposes of keeping this issue specific to the timezone issue, removed my typo fix elsewhere in the file per http://drupal.org/node/550264 - I hope that's considered good practice when patching the same file for multiple issues, please let me know if you prefer seeing a patch like this also incorporate the fix from that other ticket so I know in the future)

CommentFileSizeAuthor
#5 itworks.png61.35 KBmig5
#4 Screenshot-admin | whut.home_.mig5_.net - Mozilla Firefox-1.png64.57 KBmig5
#1 550286.patch987 bytesmig5

Comments

Anonymous’s picture

Anonymous (not verified) commented
StatusFileSize
new 550286.patch987 bytes

cheers

Macronomicus’s picture

Macronomicus commented

Hmm . well I did some tests on my dev and I am running RC3 without this issue ... however its an updated site from rc2. So technically my testing may be different then needed. I am also running RC3 on my production server without this issue .. its also an rc2 upgrade.

I also ran the patch against an instance of my dev upgraded to HEAD for all aegir bits... and everything worked fine pre/post the patch.

Im not sure but maybe this is only on virgin rc3 installs? ..or could be the result of something local to ur test environ?

Anonymous’s picture

Anonymous (not verified) commented

I first noticed this on a vanilla rc2 Aegir install, whereby default timezones of provisioned sites are simply blank (there is nothing in the provision that inserts any sort of value for this into the database).

So it's not at all related to virgin rc3 installs, happened before that.

When I get an rc3 install going properly, i'll test and see if magically it 'just works'. I have to say I was surprised, but *not* surprised that fresh provisioned sites were showing blank timezones, because I couldn't see anything in the code that would've made it work in the first place :) so now I'm even more surprised to hear it's just working off the bat for others. That's good news!

Anonymous’s picture

Anonymous (not verified) commented
StatusFileSize
new Screenshot-admin | whut.home_.mig5_.net - Mozilla Firefox-1.png64.57 KB

Just ignore this, the patch above fixes what is shown in the attached screenshot because date('Z') returns 36000 (GMT +10).

Trying to reproduce on a xen install at home, that function returns 0, so I don't know what's going on. but it means my patch doesn't work for me on my rc3 fresh install on this new xen VM. Go figure.

In any case despite the fact that this query returns zero rows for macrocosm:

select value from variable where name = 'date_default_timezone';

(which my patch fixes, on my linode), and yet his timezone is auto-detected, means this is not necessarily an Aegir bug and even if it is a bug, it's more likely a debian/php bug :)

Sorry to waste everyone's time.

Anonymous’s picture

Anonymous (not verified) commented
StatusFileSize
new itworks.png61.35 KB

Edit: dpkg-reconfigure tzdata on my home VM that was set to UTC, now is GMT+10 and date('Z') returns 36000.

But on fresh rc3 install, no upgrades, the default timezone after submitting the Reset password page is still +0000 per the screenshot above.

Apply my patch above, it sets the variable with the offset from date('Z'), and on my next provision of a site, it defaults to the correct timezone (yay, see attached screenshot). So it does work, just can't explain why macrocosm gets away without it :)

anarcat’s picture

anarcat commented

Well... doesn't it make sense that by default apache/php takes the default timezone in consideration? Maybe /your/ system was broken? ;) OR maybe it's even a problem with the drupal core that assume GMT...

Would like more testing before committing. We could get a lot of cruft in settings.php and i'd like to get just what is necessary, and nothing more.

Anonymous’s picture

Anonymous (not verified) commented

This only patches install_6.inc and install_5.inc in the provision/platform/drupal stuff :)

But yeah, no point in this being committed if it's just mig5 with the issue. Testing very welcome

anarcat’s picture

anarcat commented
Category: bug » feature
Status: Needs review » Fixed 
anarcat@hostmaster:~$ date
jeudi 20 août 2009, 10:04:31 (UTC-0400)

Created sites are not UTC-4. 'nuf said, committed. (even if it's working for some, it's not working for me and adding that variable won't make much of a difference. i was confused when i talked about settings.php, it's not setting the variable there, but just in the database, which is great.)

(Note that i think this is a feature request, but since it's so trivial and mig5 has done an excellent job in the queue, i'll pull it in anyways.)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit 09a4cc2 on debian, dev-dns, dev-envobject, dev-koumbit, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, dev-newhooks, dev-nginx, dev-platform_management, dev-ports, dev-purgebackup, dev-restore, dev-services, dev-simplerinstaller, dev-site_rename, dev-ssl, dev_716166_apache_conf, dev_dns, dev_server_verify, prod-koumbit, ssl, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x authored by anarcat: 
    #550286 by mig5 - set default timezone in deployed sites