GNU bug report logs - #56524
doc: timezone offset conversion/info

Previous Next

To reply to this bug, email your comments to 56524 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: Karl Berry <karl <at> freefriends.org>
To: bug-coreutils <at> gnu.org
Subject: doc: timezone offset conversion/info
Date: Tue, 12 Jul 2022 16:57:40 -0600

Suppose I have a date in UTC, and I want to "convert" it to a given UTC
offset, say UTC-4. Based on the date --help msg and examples, etc., I
was under the impression that the idiom is 
  TZ=<output_tz> date -d 'TZ="<input_tz>" <datestr>'

Thus, in my case:
$ TZ=UTC-4 date -d 'TZ="UTC" 2022-07-24 15:00'

The output is:
Sun Jul 24 19:00:00 UTC 2022

It adds 4 hours instead of subtracting. Why? I'm probably missing
something completely obvious, but maybe the doc could explain this.


If I use a tz name that is currently UTC-4, it subtracts as expected:
$ TZ=America/New_York date -d 'TZ="UTC" 2022-07-24 15:00'
Sun Jul 24 11:00:00 EDT 2022

Also, if I interchange the input/output tz settings, it subtracts as
expected:
$ TZ=UTC date -d 'TZ="UTC-4" 2022-07-24 15:00'
Sun Jul 24 11:00:00 UTC 2022


Overall, I suggest another example in the "Examples of date" node.
I know UTC offsets are often not the best thing to be using, but
sometimes that's the data we're given and we have to work with it.


Related: I also suggest explicitly saying how to specify UTC offsets,
because it is not clear. For one, apparently UTC+0430 is invalid since
it doesn't affect the output (no error message, which I guess is
standard):

$ TZ=UTC+0430 date -d 'TZ="UTC" 2022-07-24 15:00'
Sat Jul 23 15:00:00 UTC 2022

whereas with a colon it works as expected (well, given the above, that
it subtracts with a positive offset):
$ TZ=UTC+04:30 date -d 'TZ="UTC" 2022-07-24 15:00'
Sun Jul 24 10:30:00 UTC 2022

If the offset syntax is documented anywhere, I couldn't find it. Sorry.

BTW, in neither case did --debug clarify anything for me. In fact, it
confused me more, because the output seemingly did not include anything
about the offset at all, just reporting "UTC".

This is with coreutils 8.30 (from Alma Linux 8) on x86_64, though I
doubted that it was version-dependent, so confess I didn't try the
latest release. --thanks, karl.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Karl Berry <karl <at> freefriends.org>
Cc: 56524 <at> debbugs.gnu.org, Gnulib bugs <bug-gnulib <at> gnu.org>
Subject: Re: bug#56524: doc: timezone offset conversion/info
Date: Tue, 12 Jul 2022 17:20:59 -0700

[Message part 1 (text/plain, inline)]

On 7/12/22 15:57, Karl Berry wrote:

> $ TZ=UTC-4 date -d 'TZ="UTC" 2022-07-24 15:00'

This doesn't mean what you want, because TZ=UTC-4 means "My time zone is 
abbreviated 'UTC', and it's four hours east of Greenwich" which is not a 
useful setting.

You're not the first person to run afoul of POSIX TZ strings, which are 
poorly designed. I installed the attached patch to Gnulib to give 
another example, which I hope clarifies things a bit. I'll cc this email 
to bug-gnulib since the problem is in Gnulib not Coreutils proper.

> If the offset syntax is documented anywhere, I couldn't find it. Sorry.

It's documented in the glibc manual, and this part of the Coreutils 
manual (actually, taken from Gnulib) has a cross-reference to that.

> BTW, in neither case did --debug clarify anything for me. In fact, it
> confused me more, because the output seemingly did not include anything
> about the offset at all, just reporting "UTC".

It'd be nice if --debug could diagnose invalid TZ settings. However, 
this would likely require glibc support along the lines of what's in 
tzcode and NetBSD (the tzalloc function).

[0001-parse-datetime-improve-doc-for-TZ-07-7-etc.patch (text/x-patch, attachment)]

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

From: Karl Berry <karl <at> freefriends.org>
To: eggert <at> cs.ucla.edu
Cc: 56524 <at> debbugs.gnu.org, bug-gnulib <at> gnu.org
Subject: Re: bug#56524: doc: timezone offset conversion/info
Date: Wed, 13 Jul 2022 15:31:26 -0600

    I installed the attached patch to Gnulib 

Thanks. 

    +Simple POSIX rules like this can also specify nonzero Greenwich offsets.

Nothing about this seems "simple" to me :). Anyway.

    +More-complex POSIX TZ strings can specify simple daylight saving

There shouldn't be a hyphen after "More". --thanks again, karl.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Karl Berry <karl <at> freefriends.org>
Cc: 56524 <at> debbugs.gnu.org, bug-gnulib <at> gnu.org
Subject: Re: bug#56524: doc: timezone offset conversion/info
Date: Wed, 13 Jul 2022 19:05:22 -0700

[Message part 1 (text/plain, inline)]

On 7/13/22 14:31, Karl Berry wrote:
>      +Simple POSIX rules like this can also specify nonzero Greenwich offsets.
> 
> Nothing about this seems "simple" to me :).

I meant "simple" in comparison to the rules like 
TZ="<-05>+5<-04>,M3.2.0/2,M11.1.0/2".

Fixed by installing the attached further patch, which also omits that 
hyphen - though it keeps another similar hyphen that you didn't mention. 
"Most style guides do advise against linking 'more' to an adjective with 
a hyphen, but most also recognize that sometimes a hyphen may be 
necessary for clarity." 
<https://www.dailywritingtips.com/hyphenating-more-adjective/>

[0001-doc-parse-datetime.texi-Tweak-wording-again.patch (text/x-patch, attachment)]

Previous Next

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