Home :: Projects :: ProjectPier Project :: ProjectPier :: Issues

Localization of timezones cannot factor in Daylight Savings Time

By TheWalrus - Posted on April 3rd, 2008
Project:ProjectPier
Version:0.8.6-stable
Component:Code
Category:bug report
Priority:normal
Assigned:mattclements
Status:new
Description

Date/time information is not displayed correctly when Daylight Savings Time is in effect. The Localization::formatDateTime() function takes a timezone parameter which is a float value as defined in the Timezones class. As such, when DST is in effect, all times are listed as 1 hour earlier than they should be.

My first thought for a bug fix is to change the handling of Timezones to use an official zoneinfo identifier and allow the built-in PHP timestamp-handling code to correctly modify times based on the DST information built in to the zoneinfo timezones.

#1
Submitted by rhand on Mon, 08/24/2009 - 07:58.
Version:<none>» 0.8.5.0-Beta1

Any news on a fix for this? I am using 0.8.0.5 beta, but I have this issue as well. Time is @ GMT and not GMT+1 let alone CEST, which I need..

#2
Submitted by mattclements on Mon, 09/05/2011 - 10:30.
Version:0.8.5.0-Beta1» 0.8.6-stable
Assigned to:Visitor» mattclements

Old Post I know - but still causing an issue in the current version.

I will create a patch and upload

#3
Submitted by TheWalrus on Tue, 09/06/2011 - 13:59.

There were a few discussions and patches created, but those got dropped for some reason. Quite a few of my patches got dropped, as well as a few I had reviewed (like the clean URL patch). There is not even a working SVN repository anymore, so I have no idea where to get the development code.

I have my own hack patch that requires PHP 5.3 and uses the standard DateTimeZone class. Unfortunately, our version of PP is Frankensteinish and there's no way I could create anything close to a working patch for you. We're still using a version based on 0.8.0.5, but with a ton of bug and security fixes.

#4
Submitted by mattclements on Tue, 09/06/2011 - 14:05.

I have cloned a Git Repo that I have located: https://github.com/mattclements/ProjectPier

I will be working on this for all modifications that I make; as I have a lot of small fixes that are required for my installation - we *really* need a proper public repo for the project - phpfreak, is this possible?

Any code you have is appreciated! I can modify from there.

#5
Submitted by phpfreak on Tue, 09/06/2011 - 15:52.

I uploaded 0.8.8-alpha yesterday to github. My second attempt at using github.

I lost the 0.8.6 repo on github so I am going to redo it.

1) create new local repo with 0.8.6, tag as 0.8.6
2) push it with force to github
3) overwrite local 0.8.6 with 0.8.7 beta
4) push it to github
5) overwrite local 0.8.7 beta with 0.8.8 alpha

That way we should have all the changes on github.

Next to that I have a sync running now between my online development environment and a local machine. Ultimately this would lead to a process where github is updated and I still can keep my live online development environment.

I still have to figure out how to syncing back from github to my live online development environment (non git).

#6
Submitted by phpfreak on Wed, 09/07/2011 - 10:31.

Check this for a small script to investigate times:

http://www.projectpier.org/node/2554

#7
Submitted by mattclements on Wed, 09/07/2011 - 10:40.

Sorry - was replying to the wrong thread...

I think the issue here is not the Timezone problems, but rather an issue with how you set a timezone.
At present you can select only GMT, GMT+1 etc - however with DST moving the countries timezone - these should be set on zoneinfo identifiers (like Europe/London) rather than GMT or GMT+1

#8
Submitted by phpfreak on Wed, 09/07/2011 - 12:00.

This timezone topic is a pain. The list of valid timezones is dependent on the server. PHP simply fetches it from the underlying operating system. For some info, on time zone issues:

http://stackoverflow.com/questions/5816960/how-to-check-is-timezone-identifier-valid-from-...

I think the only proper solution is ignoring the built in solution and come up with one that works in all circumstances. But that is not easy. E.g. using a time server is not an option that will always work (e.g. you may have an in-house server without access to Internet or a time server or maybe PHP is not allowing socket traffic or your proxy wants credentials etc.).

Basically, all functions within PP that depend on server settings are a problem. An analog problem exists with file types (see the topics on upload and why some uploads fail depending on the combination client OS, browser and server OS).

#9
Submitted by mattclements on Thu, 09/08/2011 - 09:10.

I don't think it is as difficult as this - at present there is the following drop-down list within Update Profile:

<select id="profileFormTimezone" class="long" name="user[timezone]">
<option value="-12">(GMT-12:00) Eniwetok, Kwajalein</option>
<option value="-11">(GMT-11:00) Midway Island, Samoa</option>
<option value="-10">(GMT-10:00) Hawaii</option>
<option value="-9">(GMT-9:00) Alaska</option>
<option value="-8">(GMT-8:00) Pacific Time (US & Canada)</option>
<option value="-7">(GMT-7:00) Mountain Time (US & Canada)</option>
<option value="-6">(GMT-6:00) Central Time (US & Canada), Mexico City</option>
<option value="-5">(GMT-5:00) Eastern Time (US & Canada), Bogota, Lima, Quito</option>
<option value="-4">(GMT-4:00) Atlantic Time (Canada), Caracas, La Paz</option>
<option value="-3.5">(GMT-3:30) Newfoundland</option>
<option value="-3">(GMT-3:00) Brasilia, Buenos Aires, Georgetown</option>
<option value="-2">(GMT-2:00) Mid-Atlantic</option>
<option value="-1">(GMT-1:00) Azores, Cape Verde Islands</option>
<option value="0">(GMT) Greenwich Mean Time, London, Dublin, Lisbon, Casablanca, Monrovia</option>
<option selected="selected" value="1">(GMT+1:00) Amsterdam, Berlin, Rome, Copenhagen, Brussels, Madrid, Paris</option>
<option value="2">(GMT+2:00) Athens, Istanbul, Minsk, Helsinki, Jerusalem, South Africa</option>
<option value="3">(GMT+3:00) Baghdad, Kuwait, Riyadh, Moscow, St. Petersburg</option>
<option value="3.5">(GMT+3:30) Tehran</option>
<option value="4">(GMT+4:00) Abu Dhabi, Muscat, Baku, Tbilisi</option>
<option value="4.5">(GMT+4:30) Kabul</option>
<option value="5">(GMT+5:00) Ekaterinburg, Islamabad, Karachi, Tashkent</option>
<option value="5.5">(GMT+5:30) Bombay, Calcutta, Madras, New Delhi</option>
<option value="6">(GMT+6:00) Almaty, Dhaka, Colombo</option>
<option value="7">(GMT+7:00) Bangkok, Hanoi, Jakarta</option>
<option value="8">(GMT+8:00) Beijing, Perth, Singapore, Hong Kong, Urumqi, Taipei</option>
<option value="9">(GMT+9:00) Tokyo, Seoul, Osaka, Sapporo, Yakutsk</option>
<option value="9.5">(GMT+9:30) Adelaide, Darwin</option>
<option value="10">(GMT+10:00) Brisbane, Canberra, Melbourne, Sydney, Guam, Vlasdiostok</option>
<option value="11">(GMT+11:00) Magadan, Solomon Islands, New Caledonia</option>
<option value="12">(GMT+12:00) Auckland, Wellington, Fiji, Kamchatka, Marshall Island</option>
</select>

Although I am based in the "London" timezone - I have had to select the GMT+1 timezone to respect the DST times here.
I was thinking that these can be replaced as to store a varchar timezone, rather than a float that stores the number of hours different from GMT - this way we can respect the DST.

PHP supports the following timezones - which could be replaced by a number of Timezone Identifiers - we just need to work out how to map these correctly: http://php.net/manual/en/timezones.php

#10
Submitted by phpfreak on Thu, 09/08/2011 - 14:54.

I looked at that and PHP depends on the operating system.

Even if you set the default time zone, PHP finally retrieves the time zone set by the server and then determines the difference between the two. So, even if you set the correct time zone from your perspective, things may not be correct if the server is not configured properly.

#11
Submitted by TheWalrus on Sat, 09/17/2011 - 01:42.

I think two different timezone items are being discussed here:

1) PHP has a list of Timezones built into it. This list comes from the "zoneinfo" (AKA Olson) timezone database which is used by most modern non-Microsoft software and operating systems. This list has existed in PHP since 5.1.0. ProjectPier should be using this database since it is kept up to date with each PHP release.

2) PHP has a runtime configuration of a "default" timezone for all of its date functions. The PHP setting is date.timezone and (as stated on that page) prior to PHP 5.4.0 takes effect only if the process running PHP does not have the TZ environment variable set (otherwise, TZ takes precedence).

I believe phpfreak is talking about #2, while mattclements and I are talking about #1.

It is my opinion that it is up to the server operator to understand how to configure PHP correctly and ProjectPier shouldn't use convoluted code to protect what is a standard PHP library from stupid people. :) Now, we can be quite helpful to first time users by putting some code into the installation application that shows the admin what date.timezone is set to (or TZ if it is unset). We should also insert a warning if the TZ environment variable is set differently than date.timezone and the PHP version is < 5.4.0, as that will surely cause the admin confusion.

phpfreak: I'm not familiar with github. What is the URL I need to use to go have a look at the git repository?

#12
Submitted by TheWalrus on Mon, 09/19/2011 - 13:45.

@phpfreak: I found the code on github. There are quite a few items missing from the public/upgrade/templates/db_migration directory, such as addressbook_dbalteration.php, page_attachments.php, issuetracker.php, and plugin_manager.php. In addition, two mysql schemas exist under the public/install directory structure, and neither of them appear to have the correct schema necessary to run PP 0.8.8.

#13
Submitted by phpfreak on Mon, 09/19/2011 - 20:30.

Thanks.
On upgrade: I am in the process of writing a generic database update script (checks all differences between existing tables and desired tables and then fixes the differences). Apart from that we need scripts to move data from one place to another. I will check if we miss those scripts.
On schemas: The mysql directory is a left over of 0.8.5 that I forgot about while setting up github. I need to remove that complete directory.

#14
Submitted by phpfreak on Mon, 09/19/2011 - 20:46.

That whole timezone stuff is quite complex (i had to look up convoluted :-) ). I am thinking that the most simplest solution is to ignore the time zone identifier stuff completely and just let the user set the desired time offset in his profile. I still have not figured out what happens if the database is running on another server as PHP with possibly different time settings. I mean, what to do if the server is on a shared host and not properly configured and waiting for a solution of the help desk is not an option? And this may change over time... One year all is well, then an upgrade happens and suddenly your times is are incorrect. Most simplest would be to put the user in charge of changing time offset.
I do plan on delivering a page that shows the time settings of PHP server, network time, browser and MySQL.
And even PHP has bugs in it, that is why I am not happy about testing on PHP versions. Sometimes it depends not only on the version but also on the specific build (e.g. Windows 7 ok, Windows XP (32bit) wrong. Linux different, AIX ok, HP-UX wrong).

#15
Submitted by phpfreak on Mon, 09/19/2011 - 20:57.

This is the code in environment/environment.php right now. It is wrong for 0.8.8 alpha but hey, I was experimenting.

  //$timezone = config_option('timezone', 'GMT');
  $timezone = 'Europe/Sofia';
  $timezone = 'America/Anchorage';
  ini_set('date.timezone', $timezone );
  if (function_exists('date_default_timezone_set')) {
    date_default_timezone_set($timezone);
  } else {
    putenv("TZ=$timezone");
  } // if

What happened on my online server is that Europe/Sofia would simply give me a white page. It is an allowed value according to the PHP list of timezones but PHP died with an error in the log. America/Anchorage worked fine. Apparently the only safe value is GMT.
I do not think we can depend on hosters or others to configure servers properly. For first time users, it will be an immediate thumbs down for PP when this happens. For existing users it will undermine trust when a valid option is selected and the page turns white (without an option to simply go back). In the end it will not make us happy because of the many incidents that will pop up in the forum.
So, how to pick a rock solid way of handling time differences?

#16
Submitted by TheWalrus on Mon, 09/19/2011 - 21:02.

What did the PHP error log show when you used Europe/Sofia?

#17
Submitted by phpfreak on Wed, 09/21/2011 - 19:56.

I could finally reproduce the white page. This code

  //$timezone = config_option('timezone', 'GMT');
  $timezone = 'GMT';

works, but

  $timezone = config_option('timezone', 'GMT');
  $timezone = 'GMT';

generates white page. No error in the log.
The function config_option does not exist yet.
I was confused :-)

#18
Submitted by TheWalrus on Wed, 09/21/2011 - 20:01.

So there is no problem with PHP's timezone handling, correct? The issue was an error in your test page? So we can go ahead and move towards using PHP's built-in DateTime and DateTimezone classes?

#19
Submitted by phpfreak on Wed, 09/21/2011 - 20:27.

I guess so.

#20
Submitted by mattclements on Mon, 10/24/2011 - 13:25.

Have we proceeded any further with this for any of the later beta versions?