Timezone processing in case if server timezone differs from site timezone

[Alexander Obuhovich]

In most cases webserver is physically located in same timezone as website, that is hosted on it. However there are some cases, when they differ.

To overcome that we have 2 settings in configuration:

• timezone of server
• timezone of website

When they differ we add difference before date is displayed and remove difference before date is saved to database. This method however doesn't process case when daylight saving settings differ from website to server.
Since there was no other way to do that in PHP4 it's developed as is.

PHP5 offers more control over daylight saving settings via date_default_timezone_set function, that allows to set both website timezone and daylight saving settings in one call like this:

date_default_timezone_set('Europe/Moscow');

We just need to set it during script initialization and no more need to trick timestamps before saving/displaying them.

At the end we will have list of supported timezones (see http://lv.php.net/manual/en/timezones.php) instead of 2 current configuration variables.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Dmitry Andrejev]

Hi Alex,


Sounds interesting. How about we file the task and mark it for 5.2.0
since we can definitely get rid of PHP4 functionality in there.


DA.

[Alexander Obuhovich]

Since cases when timezone differs are rare, then we can wait for 5.2.0 release to fix it.

I also discovered code, that will work for PHP4 too:

putenv('TZ=Europe/Moscow');

Works for Linux.

I vote we schedule whole task as bug to existing functionality and place it to 5.1.1 release.

[Dmitry Andrejev]

Agree.

Would you please create a task and schedule for 5.1.1 then.

DA.

On Fri, May 14, 2010 at 11:58 AM, Alexander Obuhovich

[Alexander Obuhovich]

There i a lot of timezones, and that's why maybe we just allow user to type what he wants and not to show huge dropdown.

I will create a task shortly.

[Dmitry Andrejev]

I think we should provide the options instead of typing - it wouldn't be user friendly.

I see the following option here:

Have 2 dropdowns next to each other and manage it with JS.

- Continent

- Time Zone

What you think?

DA.

[Alexander Obuhovich]

It doesn't work that way. We can't create dependent configuration variables and load them via ajax, since all configuration sections are using same template.

I don't think, that hardcoding that 2 configuration variable names on that template would do us ant good.

[Dmitry Andrejev]

Okay what other options we have?

May be we should create a sub-sections inside the Configuration->Adanced which could use different Configuration templates (new one will has to be developed). Our configuration is section is getting longer and longer, don't you think?

Example:

Configuration->Advanced->Server

Configuration->Advanced->Email

and so on - not necessary we need to move all of Configuration out of Advanced, but some major ones with lots of settings can be go there.

Also, I don't think we need Ajax. I would just create a special Config template which supports having 2 dropdowns processed with JQuery JS so all values are loaded on the page.

DA.

[Alexander Obuhovich]

Here is another idea how to implement this (also using ModuleInclude tag):

• on "config_universal.tpl" template we do ModuleInclude tag on "config/custom_variables.tpl" template
• on that "custom_variables.tpl" template we define blocks, named in format "cf_<VariableName>_element", e.g. "cf_TimeZoneCountry"
• when displaying configuration variables we will look if corresponding custom block is found and render it (if found) or render using type-based block (select, text, etc.)

This way configuration variable template becomes ultra advanced and customizable. That custom block will define only right part of configuration template (where variable value is located) and left part (when variable name is shown) remains as is.

[Dmitry Andrejev]

Sounds like a solid plan to me.

Would you please document this as a separate task and relate to this one - Time Zones one?

DA.

[Phil -- wbtc.fr --]

I'm one of the timezone users, and yes, about configuration, with have actually "General" and "Advanced", which is -maybe- not enough clear for end users, as we mix server, admin and front-end settings.

We could keep these 2 categories but rename them to "admin config" and "front-end config", this could also helps in permission settings for admin.

2010/5/14 Dmitry Andrejev <dand...@gmail.com>

[Alexander Obuhovich]

"General" section wasn't designed to be "Front-End Settings" and "Advanced" wasn't designed to be "Admin Settings". All configuration sections throughout the system (even ones, that In-Link, In-Bulletin, etc. defines) define both admin and front-end settings.

Relocation of existing configuration variables is not question to be discussed in this discussion for sure.

[Phil -- wbtc.fr --]

that's right, at least having an easy system for timezone can be interesting, for example people in France are using Godaddy hosting as they buy the domain name with them.

2010/5/15 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

Task: http://tracker.in-portal.org/view.php?id=743