TZ=GMT+1 for date command is NOT working?
Peter Ohoven
I am logged in on a computer which is in Timezone PDT
When I enter now:
date
then the remote computer gives me:
Sat May 24 02:01:18 PDT 2008
When I enter then:
TZ=GMT+1 date
then the computer returns:
Sat May 24 08:01:36 GMT 2008
First error: The Timestamp return should from my view return "GMT+1" and not only "GMT".
Second error: The time is wrong. It should return either at least
Sat May 24 10:01:36 GMT 2008
or even better:
Sat May 24 11:01:36 GMT+1 2008
So even I subtract the possibly not considered daylight saving hour lag the time is wrong.
What's the error?
Peter
dillinger
Check this page:
http://www.gnu.org/software/coreutils/manual/html_node/Specifying-time-zone-rules.html
TZ="Europe/Berlin" date
should give you the correct local time and timezone:
Sat May 24 13:28:02 CEST 2008
TZ=anything date returns:
Sat May 24 11:29:33 anything 2008
Which is the hardware time of the computer, normally UTC (GMT).
Michel.
Bill Marcum
The value of TZ can be one of three formats. The first format is used
when there is no daylight saving time in the local time zone:
std offset
The std string specifies the name of the time zone and must be three or
more alphabetic characters. The offset string immediately follows std
and specifies the time value to be added to the local time to get Coor‐
dinated Universal Time (UTC). The offset is positive if the local time
zone is west of the Prime Meridian and negative if it is east.
Joachim Schmitz
1st Frankfurt/Germany is GMT-1, not GMT+1 (yes, I don't understand the logic
either the clock shows 1 houre later than GMT, but that's the way it is).
2nd the TZ name is CET not GMT, TZ=CET-1
3rd Germany observers Summer/Daylight savinges time, so currently it is
TZ=CEST-2
The full TZ (which works thoughout the year, every year) is
TZ="CET-1CEST-2,M3.5.0,M10.5.0"
Bye, Jojo
Kees Theunissen
> The full TZ (which works thoughout the year, every year) is
> TZ="CET-1CEST-2,M3.5.0,M10.5.0"
Don't be too sure about this "works [...] every year" claim. The
DST rules changed often in the past, and likely will change again
in the future. The last change for Germany was in 1996.
Processing of historical timestamps will fail with your fixed rule
in the TZ environment variable. Defining the right zoneinfo file in
the TZ variable will handle rule changes properly.
The partial dump of the Europe/Berlin zoneinfo file below shows
the last change for Germany.
~$ /usr/sbin/zdump -v /usr/share/zoneinfo/Europe/Berlin |grep -E '199(5|6)'
/usr/share/zoneinfo/Europe/Berlin Sun Mar 26 00:59:59 1995 UTC = Sun
Mar 26 01:59:59 1995 CET isdst=0 gmtoff=3600
/usr/share/zoneinfo/Europe/Berlin Sun Mar 26 01:00:00 1995 UTC = Sun
Mar 26 03:00:00 1995 CEST isdst=1 gmtoff=7200
/usr/share/zoneinfo/Europe/Berlin Sun Sep 24 00:59:59 1995 UTC = Sun
Sep 24 02:59:59 1995 CEST isdst=1 gmtoff=7200
/usr/share/zoneinfo/Europe/Berlin Sun Sep 24 01:00:00 1995 UTC = Sun
Sep 24 02:00:00 1995 CET isdst=0 gmtoff=3600
/usr/share/zoneinfo/Europe/Berlin Sun Mar 31 00:59:59 1996 UTC = Sun
Mar 31 01:59:59 1996 CET isdst=0 gmtoff=3600
/usr/share/zoneinfo/Europe/Berlin Sun Mar 31 01:00:00 1996 UTC = Sun
Mar 31 03:00:00 1996 CEST isdst=1 gmtoff=7200
/usr/share/zoneinfo/Europe/Berlin Sun Oct 27 00:59:59 1996 UTC = Sun
Oct 27 02:59:59 1996 CEST isdst=1 gmtoff=7200
/usr/share/zoneinfo/Europe/Berlin Sun Oct 27 01:00:00 1996 UTC = Sun
Oct 27 02:00:00 1996 CET isdst=0 gmtoff=3600
Regards,
Kees.
--
Kees Theunissen.
Joachim Schmitz
> Joachim Schmitz wrote:
>> The full TZ (which works thoughout the year, every year) is
>> TZ="CET-1CEST-2,M3.5.0,M10.5.0"
>
> Don't be too sure about this "works [...] every year" claim. The
> DST rules changed often in the past, and likely will change again
> in the future. The last change for Germany was in 1996.
> Processing of historical timestamps will fail with your fixed rule
> in the TZ environment variable. Defining the right zoneinfo file in
> the TZ variable will handle rule changes properly.
comp.unix.shell, and I also missed the stupid 'Follow-Up-To') and not every
POSIX copliant OS does have zoneinfo. On those systems, however, the setting
I described is to be prefered over fixed days for the switching as that
would need to get calculated and changed once a year, while 'my' setting
only needs to get changed on the relavily rare occasions when the law
changes.
Bye, Jojo
Geoff Clare
>> TZ=GMT+1 date
>> First error: The Timestamp return should from my view return "GMT+1"
>> and not only "GMT".
>> Second error: The time is wrong.
> man 3 timezone (Debian or Ubuntu must have manpages-dev package installed):
>
> The value of TZ can be one of three formats. The first format is used
> when there is no daylight saving time in the local time zone:
>
> std offset
>
> The std string specifies the name of the time zone and must be three or
> more alphabetic characters. The offset string immediately follows std
> and specifies the time value to be added to the local time to get Coor-
> dinated Universal Time (UTC). The offset is positive if the local time
> zone is west of the Prime Meridian and negative if it is east.
And if the OP really wants "GMT+1" as the timezone name, he could try:
TZ="<GMT+1>-1" date
This works on systems that conform to POSIX.1-2001 (tested on Solaris 10),
but it appears that Linux doesn't (yet?) support this use of '<' and '>'.
--
Geoff Clare <net...@gclare.org.uk>
Stephane CHAZELAS
[...]
> And if the OP really wants "GMT+1" as the timezone name, he could try:
>
> TZ="<GMT+1>-1" date
>
> This works on systems that conform to POSIX.1-2001 (tested on Solaris 10),
> but it appears that Linux doesn't (yet?) support this use of '<' and '>'.
More precisely, it is not supported by the GNU libc but it is
supported by uclibc, so it depends which /Linux/ you're talking
of.
It doesn't seem to be supported by Solaris 8. Is it a recent
addition to the standard?
--
Stéphane
jpd
On 24 May 2008 09:08:04 GMT, Peter Ohoven <p....@hotmail.com> wrote:
> Currently I am sitting here in the Timezone GMT+1 (Frankfurt/Germany).
If you're in Frankfurt, you'll be in CET/MEZ TZ, which is currently
actually CEST (CET+daylight savings) and as such GMT+2.
On my (FreeBSD) system, sh -c 'TZ=CET date' gives the expected result:
Wed May 28 07:05:34 CEST 2008
Whether using GMT+/-N notation does useful things I won't comment on,
but I will say that using ``unsupported'' values for TZ= can silently
cause interesting results.
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.
Joachim Schmitz
> Begin <4837daf4$0$7534$9b4e...@newsspool1.arcor-online.net>
> On 24 May 2008 09:08:04 GMT, Peter Ohoven <p....@hotmail.com> wrote:
>> Currently I am sitting here in the Timezone GMT+1
>> (Frankfurt/Germany).
>
> If you're in Frankfurt, you'll be in CET/MEZ TZ, which is currently
> actually CEST (CET+daylight savings) and as such GMT+2.
Or better:
CEST-2
Both setiing result in the correct time being displayed, but the earlier in
a wrong timezone to be shown.
the -2 is the offset to GMT/UTC, so it indicates by how many hours GMT/UTC
is off, which is indeed 2 hours for CEST
Bye, Jojo
Stephane Chazelas
> Begin <4837daf4$0$7534$9b4e...@newsspool1.arcor-online.net>
> On 24 May 2008 09:08:04 GMT, Peter Ohoven <p....@hotmail.com> wrote:
>> Currently I am sitting here in the Timezone GMT+1 (Frankfurt/Germany).
>
> If you're in Frankfurt, you'll be in CET/MEZ TZ, which is currently
> actually CEST (CET+daylight savings) and as such GMT+2.
>
> On my (FreeBSD) system, sh -c 'TZ=CET date' gives the expected result:
>
> Wed May 28 07:05:34 CEST 2008
>
> Whether using GMT+/-N notation does useful things I won't comment on,
> but I will say that using ``unsupported'' values for TZ= can silently
> cause interesting results.
BTW, I don't know if it has be mentionned already, but the
GMT+xxx is obtained by date +GMT%z, not date +%Z
Note that in some locales on some systems the default date
output has the GMT offset rather than the timezone name.
~$ date
Wed May 28 09:43:15 BST 2008
~$ LC_TIME=fr_FR date
mercredi 28 mai 2008, 09:43:21 (UTC+0100)
~$ locale date_fmt
%a %b %e %H:%M:%S %Z %Y
~$ LC_TIME=fr_FR locale date_fmt
%A %-e %B %Y, %H:%M:%S (UTC%z)
(that's with GNU libc).
BST is British Summer time which is one hour east of GMT
defined as BST-1
Mnemonic: <TZ variable> == GMT
So BST == GMT + 1
gives BST - 1 == TZ
--
Stéphane