php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #39050 Etc/GMT+/- x hours values are backwards
Submitted: 2006-10-05 14:28 UTC Modified: 2006-10-05 16:29 UTC
From: duerra_NOT_THIS_ at pushitlive dot net Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 5.1.6 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: duerra_NOT_THIS_ at pushitlive dot net
New email:
PHP Version: OS:

 

 [2006-10-05 14:28 UTC] duerra_NOT_THIS_ at pushitlive dot net 
Description:
------------
When using Etc/GMT related values with date_default_timezone_set(), the values are backwards of what they should be.  

Reproduce code:
---------------
<?php
date_default_timezone_set('Etc/GMT');
echo date('H:i').'<br />';
date_default_timezone_set('Etc/GMT-1');
echo date('H:i');
?>

Expected result:
----------------
14:27
13:27

Actual result:
--------------
14:27
15:27

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-10-05 14:34 UTC] derick@php.net 
No, those are correct. However, you should not even be using those - they only exist in the timezone database for backward compatible reasons. Pick one of the Continent/City combinations.
 [2006-10-05 16:06 UTC] duerra_NOT_THIS_ at pushitlive dot net 
How is that correct?  My time zone is GMT-6 hours, not GMT+6 hours.  I even noticed that it is noted in the user-contributed notes as being backwards.

Also, I realize that I "should not be using" those values according to the documentation, but PHP depricating those is lunacy, because having a select dropdown of hundreds of locations/cities for an end user to pick from for locale reasons is confusing and tedius.  Those values should not be depricated - they are useful, minimal, and concise.  The same cannot be said about selecting a city out of hundreds of cities worldwide.  Sure it is valid and useful for some instances, but definitely not for time zone configuration for end users on a site - and nor is developing a workaround system because useful features are depricated in the language.  I can understand depricating other values but not the Etc/GMT* values.

PHP really needs to reconsider this.  I also still do not understand how the values provided with those settings are the correct values.  GMT-6 hours would be US/Central, but I'm given the value of somewhere in Australia.  That is not correct.
 [2006-10-05 16:29 UTC] derick@php.net 
Your OS does the same for example:

derick@kossu:~$ TZ=UTC date
Thu Oct  5 16:26:02 UTC 2006

derick@kossu:~$ TZ=GMT-2 date
Thu Oct  5 18:26:07 GMT 2006

derick@kossu:~$ TZ=GMT+6 date
Thu Oct  5 10:26:11 GMT 2006

The explanation (from the timezone database definition files) why it is like this:

# We use POSIX-style signs in the Zone names and the output abbreviations,
# even though this is the opposite of what many people expect.
# POSIX has positive signs west of Greenwich, but many people expect
# positive signs east of Greenwich.  For example, TZ='Etc/GMT+4' uses
# the abbreviation "GMT+4" and corresponds to 4 hours behind UTC
# (i.e. west of Greenwich) even though many people would expect it to
# mean 4 hours ahead of UTC (i.e. east of Greenwich).


The timezones you can specify in PHP come directly from this database, just like it would have been before (in PHP 4 and 5.0). They also do not take care of daylight savingstime either so they're definitely not useful and concise. Nothing in PHP is deprecated either as before you'd do this with the putenv("TZ=xxx") env var which would have given you the exact same result.

Definitely a bogus bug.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Mon Jul 21 10:00:02 2025 UTC