GNU bug report logs - #11748
date: "Asia" Timezone

Previous Next

To reply to this bug, email your comments to 11748 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: bug-coreutils <at> gnu.org
Subject: "Asia" Timezone
Date: Tue, 19 Jun 2012 16:00:54 -0400

I was recently showing off ...
and I entered the following command

$ date && TZ=Asia/Moscow date
Tue Jun 19 15:48:14 EDT 2012
Tue Jun 19 19:48:14 Asia 2012
$ TZ=Europe/Moscow date
Tue Jun 19 23:48:59 MSK 2012

My initial reaction, besides some embarrassment
at getting the continent wrong (and most of
Russia's timezone are in Asia), is that this
is a bug in the coreutils date command.
However, I've also posted this info to the
iana timezone mailing list, just in case.

It's a double bug. The date command is printing
out a non-existent timezone, and it's using GMT for
"Asia".

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Message #8 received at 11748 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Boruch Baum <boruch_baum <at> gmx.com>
Cc: 11748 <at> debbugs.gnu.org
Subject: Re: bug#11748: "Asia" Timezone
Date: Wed, 20 Jun 2012 09:23:58 +0100

On 06/19/2012 09:00 PM, Boruch Baum wrote:
> I was recently showing off ...
> and I entered the following command
> 
> $ date && TZ=Asia/Moscow date
> Tue Jun 19 15:48:14 EDT 2012
> Tue Jun 19 19:48:14 Asia 2012
> $ TZ=Europe/Moscow date
> Tue Jun 19 23:48:59 MSK 2012
> 
> My initial reaction, besides some embarrassment
> at getting the continent wrong (and most of
> Russia's timezone are in Asia), is that this
> is a bug in the coreutils date command.
> However, I've also posted this info to the
> iana timezone mailing list, just in case.
> 
> It's a double bug. The date command is printing
> out a non-existent timezone, and it's using GMT for
> "Asia".

So this is due to TZ needing to support two formats.
POSIX and location based.

The POSIX format is a zone[+offset] format, though
is nonsensical and best avoided as detailed here:
http://www.pixelbeat.org/docs/linux_timezones/index.html

The location based format is what you were trying
to use here, but date fell back to the POSIX format
when there was no match.

Now on GNU/Linux you could warn if there was
no match for TZ with a leading ':' or non number after '/'
But I can't see a way to determine if tzset(3) did
find a match or not :(

cheers,
Pádraig.

Message #17 received at 11748 <at> debbugs.gnu.org (full text, mbox):

From: Boruch Baum <boruch_baum <at> gmx.com>
To: 11748 <at> debbugs.gnu.org
Subject: Re: bug#11748 acknowledged by developer ()
Date: Mon, 15 Oct 2018 17:21:00 -0400

What is the basis for closing this bug report? The issue has not yet
been fixed (6+ years and counting...).


On 2018-10-15 13:11, GNU bug Tracking System wrote:
> This is an automatic notification regarding your bug report
> #11748: date: "Asia" Timezone,
> which was filed against the coreutils package.
>
> Thank you for your report, which has now been closed.
> You can view the full report at
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11748
>
> If you require further information, please followup to 11748 <at> debbugs.gnu.org.
>
> debbugs.gnu.org maintainers
> (administrator, GNU bugs database)
>

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Message #28 received at 11748 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Boruch Baum <boruch_baum <at> gmx.com>, 11748 <at> debbugs.gnu.org
Subject: Re: bug#11748: acknowledged by developer ()
Date: Mon, 15 Oct 2018 16:45:00 -0700

On 10/15/18 2:21 PM, Boruch Baum wrote:
> What is the basis for closing this bug report? The issue has not yet
> been fixed (6+ years and counting...).

The problem is not actually a bug, in that the behavior of 
"TZ=Asia/Moscow date" is deliberately not specified by POSIX or by the 
coreutils documentation, and coreutils 'date' can therefore do whatever 
it likes when misused in that way. That being said, it would be nicer if 
coreutils 'date' issued a usable diagnostic rather than simply treating 
the invocation as if it were "TZ=Asia0 date". Unfortunately, though, 
there's no standardized-by-POSIX or GNU-available way for application 
programs to do that, and although adding a glibc feature to provide a 
way to do it is on my list of things to do (see 
<https://sourceware.org/bugzilla/show_bug.cgi?id=11620>), I have a long 
list.

To help record all this better, I reopened the bug report, made it 
'wishlist', merged it with Bug#9614 and Bug#14229, and invite anyone 
who's interested to add support for the request. The heavy lifting here 
is not in Coreutils proper, though; it's Glibc bug 11620, referenced above.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.