Re: use of TZ by mktime()/strftime()

[Bob Proulx]

Andrew J. Schorr wrote:
> bash-5.1$ TZ=US/Eastern date
> Tue Aug  9 01:46:40 PM EDT 2022
> bash-5.1$ TZ=EST date
> Tue Aug  9 12:46:56 PM EST 2022
> bash-5.1$ TZ=US/Pacific date
> Tue Aug  9 10:46:43 AM PDT 2022
> bash-5.1$ TZ=PDT date
> Tue Aug  9 05:47:48 PM PDT 2022
> bash-5.1$ TZ=UTC date
> Tue Aug  9 05:46:58 PM UTC 2022
> bash-5.1$ TZ=IST date
> Tue Aug  9 05:47:00 PM IST 2022
>
> It seems that "date -d" can grok some time zone names that don't work
> when set in the TZ environment variable.

This is one of those topics that pops up repeatedly.  Timezones are a
feature of libc and glibc does not know anything about IST as a
timezone.  Therefore asking for IST falls back to UTC.  As glibc does
for any unknown timezone.  But glibc makes no indication of this
failure fallback to UTC at any point.  I do wish it would cause some
type of error so that the caller would know that what they are doing
is falling back to UTC.

There is an GNU date FAQ entry that contains a lot of gathered up
information about working with GNU date.

    
https://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e

But on glibc systems the glibc TZ variable documentation is authoritative.

    https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

Which even gives an example using IST.  I don't like it though since
it requires creating a definition of IST on the command line.  That
feels very bad to me to be hard coding this information there.  Look
at this horror.

    $ TZ=IST-2IDT,M3.4.4/26,M10.5.0 date -R -d '2022-08-01 12:00'
    Mon, 01 Aug 2022 12:00:00 +0300

Use TZ=Asia/Jerusalem instead.

    $ TZ=Asia/Jerusalem date -R -d '2022-08-01 12:00'
    Mon, 01 Aug 2022 12:00:00 +0300

The standards docs describing TZ are available online.  Though if you
can read this through and understand it without examples then you are
a much better reader of standards than I.

    https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

Padraig Brady maintains a page with some information about this too.

    https://www.pixelbeat.org/docs/linux_timezones/

I'll summarize and say that even if in conversation here I might say I
am in MDT for US Mountain Daylight Time that using those types of
timezones are inherently problematic.  Never do this in a program.  I
might use TZ=US/Mountain for myself because I know that works for me.
But in general that is also problematic because it does not work in
Arizona.  Use TZ=America/Phoenix instead.

As a parting hint GNU date can parse the timezone from the TZ variable
in the -d,--date= argument and this overrides the environment variable
or global system setting.  Therefore really when using GNU date one
should not do something like -d '2022-01-01 12:00:00 IST' but instead
use -d 'TZ="Asia/Jerusalem" 2022-01-01 12:00:00' with careful use of
the required double quoting.

    $ TZ=America/Denver date -R --date='TZ="Asia/Jerusalem" 2022-01-01 12:00:00'
    Sat, 01 Jan 2022 03:00:00 -0700

Hope this helps!
Bob