[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Confusion with Etc/GMT-8 time zone

Amit wrote:
> Currently, my time zone is set to 'America/Los_Angeles':
>  $ cat /etc/timezone
>  America/Los_Angeles
>  $ date
>  Mon Jan 28 11:12:01 PST 2013

It is easier to work with these by using the TZ variable while
developing and debugging.  It avoids the need to change anything
permanently on the system.  It gives other people the ability to
recreate your test case easily.

Also, the default date format is ambiguous in terms of timezone names.
Therefore I recommend using -R to get one of the standard formats.
(Or "+%F %T %z" too.)

  $ TZ=America/Los_Angeles date -R
  Mon, 28 Jan 2013 17:06:41 -0800

> Changing it to 'Etc/GMT-8', which should be equivalent to Los Angeles's
> time zone results in:

No!  GMT-8 is NOT equivalent to Los Angeles's time zone.  That is the
root of this problem.  The sign is opposite.

Also using the GMT+/-offset formats ignores any daylight savings time
that will be in effect.  Therefore it won't ever be equivalent even if
the sign of the offset is correct.

>  $ echo "Etc/GMT-8" | sudo tee /etc/timezone
>  Etc/GMT-8

Easier to set the TZ variable to the filename you are wishing to use.
This is the third format supported by glibc.  In this case you can use
a relative filename.

  $ TZ=:Etc/GMT-8 date -R
  Tue, 29 Jan 2013 09:09:57 +0800

Notice that +0800 timezone?  It is already tomorrow there.

> Notice that the day moved to Jan  29th. This doesn't seem to make any
> sense. Is this a bug?

The bug is that Los Angeles is currently -8 hours from GMT not +8
hours and therefore the timezone cannot be GMT-8.

I think you have read the documentation incorrectly.  The current
documentation matching your currently installed version is
available using this command:

  $ info -f libc 'TZ Variable'

The upstream documentation for the latest version (may be newer than
what is installed on your system) is here:


     The first format is used when there is no Daylight Saving Time (or
  summer time) in the local time zone:


     The STD string specifies the name of the time zone.  It must be
  three or more characters long and must not contain a leading colon,
  embedded digits, commas, nor plus and minus signs.  There is no space
  character separating the time zone name from the OFFSET, so these
  restrictions are necessary to parse the specification correctly.

And here is the important part:

     The OFFSET specifies the time value you must add to the local time
  to get a Coordinated Universal Time value.  It has syntax like
  [`+'|`-']HH[`:'MM[`:'SS]].  This is positive if the local time zone is
  west of the Prime Meridian and negative if it is east.  The hour must
  be between `0' and `23', and the minute and seconds between `0' and

     For example, here is how we would specify Eastern Standard Time, but
  without any Daylight Saving Time alternative:


The intention was to specify a local timezone name and the offset from
it to get back to UTC.  Not to specify GMT with an offset.  The name
of the zone isn't important.  It is only the offset to get back to UTC
that is important.  (And so I do not like the GMT+/-offset files
shipped with Debian.  Having them makes no sense to me.)

Since Los Angeles is currently -8 hours it means the the offset must
be +8 for your example case.  Ignoring DST.

  $ TZ=GMT+8 date -R
  Mon, 28 Jan 2013 17:18:32 -0800

Most importantly though will be the documentation in the tzdata file
source which says:

# 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).
# In the draft 5 of POSIX 1003.1-200x, the angle bracket notation allows for
# TZ='<GMT-4>+4'; if you want time zone abbreviations conforming to
# ISO 8601 you can use TZ='<-0400>+4'.  Thus the commonly-expected
# offset is kept within the angle bracket (and is used for display)
# while the POSIX sign is kept outside the angle bracket (and is used
# for calculation).
# Do not use a TZ setting like TZ='GMT+4', which is four hours behind
# GMT but uses the completely misleading abbreviation "GMT".

And therefore you would be expected to use PST or some such in that
timezone abbreviation.

  $ TZ=PST+8 date -R
  Mon, 28 Jan 2013 17:35:06 -0800

  $ TZ=PST+8 date
  Mon Jan 28 17:41:14 PST 2013

But I strongly recommend using the appropriate zone data files
instead.  That way DST is handled properly.

  $ TZ=US/Pacific date -R
  Mon, 28 Jan 2013 17:24:07 -0800

  $ TZ=America/Los_Angeles date -R
  Mon, 28 Jan 2013 17:24:30 -0800

> NOTE: Repeating the above steps for Etc/GMT+8 results in the correct and
> expected time.

Right!  :-)


Attachment: signature.asc
Description: Digital signature

Reply to: