s9y GMT offset

[abdussamad]

Hello

Currently s9y uses server time offset to determine the correct time. I move my s9y sites from server to server a lot and I find that different servers are set to different time zones. Therefore I always have to change the server time offset in s9y admin suite. This change also means that the timestamps of older posts are screwed up.

Most other CMS use GMT/UTC offset because that is server independent. Drupal and wordpress are examples. I request that the s9y developers consider using GMT/UTC offset instead of server time offset for future s9y versions.

Thank you,
Abdussamad

[garvinhicking]

Hi!

I'm really bad with timezones. If someone can help with implementation, that would be great.

Since s9y already uses the serendipity_serveroffsetHour() abstraction, this could be t he starting point to implement GMT offsets.

Of course it somehow needs to be ensured that users using the old method will not get screwed up posting times, but the change is optional so that the user can either use GMT offset or Server offset?

Regards,
Garvin

[abdussamad]

The function you mentioned is only used when displaying the time. But if we want to use GMT instead of the server time we need s9y to save the GMT time as the blog entry timestamp. Unfortunately whenever it comes to saving the time s9y is using the time() function not any wrapper function. In fact time() is used all over the place including the archives plugin. time() always returns the server time.

So the easiest solution is to set the default timezone using the date_default_timezone_set() or in .htaccess using php_value date.timezone. This function is found in php 5.1 and later only. Once you do date_default_timezone_set('UTC') all future time() and date() calls return UTC time not server time.

So If I take the php approach:

Code: Select all

if (function_exists(date_default_timezone_set))
{
//check new s9y config option to toggle gmt/server time
if($serendipity['useServerOffset']==false){
date_default_timezone_set('UTC');
}}
 

Where to add the above code? Somewhere in serendipity_config.inc.php I suppose. It has to be late enough that admin config options are loaded and before any time() calls. Any suggestions as to where I can add this?

Alternatively how do I make s9y add php_value date.timezone "UTC" in .htaccess?

[garvinhicking]

Hi!

The best place for this would be the the serendipity_config.inc.php file, I'd put it before/after the "if defined('DATE_LOCALES')" check?

If you use a config value "useUTCServerOffset" that you could add to include/tpl/config_local.inc.php, you could set the timezone there. useServerOffset is usually a number with an offset, so I wouldn't recommend using the same variable to see whether you want UTC-Timezones?

The PHP approach looks better to me, because then the function would only be used when its available?

Regards,
Garvin

[abdussamad]

I had other things on my plate so I couldn't get to this sooner. Attached are the diff files based on the last nightly that I downloaded - s9y_200905012342.tar.gz .

[garvinhicking]

Hi!

Thanks for the patch. I am wondering why the UTC timezone is applied when the variable is set to == false? Shouldn't it be only applied when it's true?

When someone updates his s9y without going to the configuration, $serendipity['useServerOffset'] will always be == false...?

Regards,
Garvin

[abdussamad]

Hi!

Thanks for the patch. I am wondering why the UTC timezone is applied when the variable is set to == false? Shouldn't it be only applied when it's true?

When someone updates his s9y without going to the configuration, $serendipity['useServerOffset'] will always be == false...?

Regards,
Garvin

Well here is what the new config option useServerOffset asks the user:

Base offset on server time?
Offset entry times on server time or not. Select yes to base offset on server time and no to offset on GMT.

So as you can see from the above the question is whether to use server time as the base for the offset or not. Therefore only if the user selects no (false) do we use GMT instead. The default option is yes (true) :


$res['display']['items'][] = array('var' => 'useServerOffset',
'title' => INSTALL_OFFSET_ON_SERVER_TIME,
'description' => INSTALL_OFFSET_ON_SERVER_TIME_DESC,
'type' => 'bool',
'default' => true,
'permission' => 'blogConfiguration'
);


By default server time will be used as the base for the offset.

[garvinhicking]

Hi!

But I think that the new default behaviour should be to leave things as they were for the user. Always enabling the UTC-timezone might introduce problems for users where time offsets have worked fine in the past. Thus, the new option should really only take effect, when the user specifically enabled that behaviour? What do you think?

And if it should default to "true", you must check the serendipity option if it's unset, and if it is, set it to "true". Otherwise, the variable evalutes to "false" which leads to the application of the new timezone behaviour...

You can simulate what I mean by deleted the "useServerOffset" variable from the serendipity_config DB table, which is about the same like any current s9y user upgrading his system, and where the variable is not yet present...

Regards,
Garvin

[abdussamad]

Hi!

But I think that the new default behaviour should be to leave things as they were for the user. Always enabling the UTC-timezone might introduce problems for users where time offsets have worked fine in the past. Thus, the new option should really only take effect, when the user specifically enabled that behaviour? What do you think?

And if it should default to "true", you must check the serendipity option if it's unset, and if it is, set it to "true". Otherwise, the variable evalutes to "false" which leads to the application of the new timezone behaviour...

You can simulate what I mean by deleted the "useServerOffset" variable from the serendipity_config DB table, which is about the same like any current s9y user upgrading his system, and where the variable is not yet present...

Regards,
Garvin

Ok I changed the code to check whether the variable was set or not. I tested it in the manner you suggested and the new code works. Diff files attached again. As before they are based on the s9y nightly s9y_200905012342.tar.gz:

[Don Chambers]

Abdussamad,

You and Garvin are doing a great job of working this out. I just wanted to say that I sincerely appreciate what you continue to do for the s9y community!!! You have been, and continue to be, a great contributor to this project. Thanks!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[garvinhicking]

Hi!

Great, that looks solid. I've just committed it! Anyone requirng such timezones, please tell me if that works out for you

Regards,
Garvin