Timezone and date display - r398, r415

[hameau]

Hello,

In a default installation of GS v.3.0B_r398, the front end is running with the timezone set to America/New_York, which is somewhat bizarre. This is a regression from GS v.2.03.

(A search through the installed files finds no mention of date_default_timezone_get() – is there no check of the server's details?)

Perhaps a separate server TZ setting in the backend, to allow for servers being in a different zone to the intended site audience?

Also, there is an error in the displayed date of website backup files in Backups->Website_Archives. The time of the archive is displayed one hour later than the file timestamp. (I see that errors of one hour have been reported before.)

Server: Debian 6.0 2.6.32-5-686; Apache/2.2.16 (Debian); PHP/5.3.3-7+squeeze1; TZ Europe/Paris

[Connie]

why don't you set the timezone yourself?

It's all in the settings, go to Setting / User Profile / Local Timezone

I did not check about the archive date, but I know that you can define the date here

[hameau]

It's all in the settings ...

Of course, it is already set in Settings. AFAIK, that only affects the logged-in user, not the public front-end.

Try putting

Code:

<?php echo date('e'); ?>

in the template and see what it shows.

[Connie]

<?php echo date('e'); ?>

will do!

you are right, that's not correct.

[hameau]

Edit: not sure what I'm talking about – sorry.

[ccagle8]

@hameau: ha, so is this a problem or isn't it? I want to make sure we get it fixed if its a problem...

[Connie]

my "will do" was misunderstandable.. I meant "I will do, I will place into template and see.."

yes, it is a problem.

Backups should get the timestamp which belongs to country-code in gsconfig.php or you use the datesetting which is set by the backend-user

[hameau]

Sorry, it was only post #5 that I was unsure about.

Timezone: yes, I think this could be a problem for a site that isn't expecting to be in UTC+5 and uses php for critical date stuff. More importantly, the fact that there is some sort of unexpected and undocumented TZ manipulation of the server's php environment.

Site Archive filenames: (this was the bit that I was addressing in post #5) I'm trying to get a better idea of what's happening. There are a couple of other (minor, I guess) problems --. e.g., if two different admins are in different TZs, not so uncommon these days, whose TZ is used in order to avoid dates in the future for one of them; if two backups are made within the same minute, the first is overwritten.

Using UTC throughout would solve some of this, but then give rise to user confusion, no doubt. A timestamp to include the real-time seconds would solve the overwriting, but the function lngDate() can't handle that at the moment.

[ccagle8]

Ok, so is it this that is causing the problem? http://code.google.com/p/get-simple-cms/...on.php#149 I would think that if we are pulling & using the timezone from the Settings, then it should work. Please help me understand where it's going wrong.

I will take a look at the Archive Times, but this may be an extension of the same problem. Do you agree?

Two backups taken the same minute should be the same anyway , but we can look into that.

Making certain actions are attached to a user is part of the 3.1 roadmap. I wanted to make sure we got the user functions working perfectly first before implementing tracking. Making sure things in different timezones are taken into account will be part of that.

[hameau]

Please help me understand where it's going wrong.

Easily said ...

I think it's something not working properly in the 'grab user data' block, http://code.google.com/p/get-simple-cms/...on.php#116. In my case, (!isset($base)) is false and it's line 136 setting the server TZ. Same behaviour if I'm logged in to the admin or not.

I will take a look at the Archive Times, but this may be an extension of the same problem. Do you agree?

Two backups taken the same minute should be the same anyway , but we can look into that.

I'm not familiar enough with GS to know what's happening with the archive times. I'd suggest that it's not a show-stopper for v3.0, but I'll try to gather a bit more info. – there's certainly something not quite right. The same with overwriting the backup archives – not critical, but it all contributes to a quality project.

Making certain actions are attached to a user is part of the 3.1 roadmap. I wanted to make sure we got the user functions working perfectly first before implementing tracking. Making sure things in different timezones are taken into account will be part of that.

Understood.

[hameau]

Okay, for the site archive date display, this is my analysis of what's going on. Filenames and line numbers relative to r415.

Archive .zip filename is generated using

Code:

$timestamp = date('Y-m-d-Hi'); // admin/zip.php, line 21

producing a timestamp in local time, according to the value of Settings->User Profile->Local Timezone of the logged-in user.

When the list of site archives is displayed, the date shown is derived from the filename. The filename is exploded (admin/archive.php, line 71) and the date/time from the front of the filename is passed to function lngDate() for formatting according to the active language file setting DATE_AND_TIME_FORMAT:

Code:

$data = date(i18n_r('DATE_AND_TIME_FORMAT'), strtotime($dt)); // admin/inc/basic.php, line 259

Unfortunately, strtotime() expects to be passed a Unix timestamp (i.e., UTC), it's actually getting a local time (UTC +/- offset). Function date() adds the local offset again, so in fact the time value returned for display is (UTC + 2*offset).

My date display of one hour error is due to my local timezone being UTC+1; by temporarily setting the User Profile to UTC+2, I get a two hour error.

Suggested (easiest) resolution:

Code:

admin/zip.php, line 21:

---  $timestamp = date('Y-m-d-Hi');
+++  $timestamp = gmdate('Y-m-d-Hi');

This will give the .zip file a timestamp in UTC. The archive display in the backend will always show that time in the User's local timezone, according to the profile setting.

Possible drawback: it would be possible to have an archive filename with the previous day's date, if the user is in a TZ with a large offset from UTC. This may cause confusion when archives are downloaded, apparently with the wrong date on them. Adding the offset to the filename might be a solution:

Code:

$timestamp = gmdate('Y-m-d-Hi') .'_'. date('O'); // admin/zip.php, line 21

producing a filename formatted 2011-03-22-0927_+0100_archive.zip for a backup taken at 10:27, local time. No changes are required elsewhere in GS.

Edit: Can't have a '+' sign in the filename – prevents deleting the file (corrupted by the HTTP GET?). You can have gmdate('Y-m-d-Hi_s') to accommodate multiple archives per minute. ;-)