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

[Neil R. Ormos]

Ed Morton wrote:
> Eli Zaretskii wrote:
>> [arnold@skeeve.com wrote:]
>>> Ed Morton wrote:

>>>> So in the above setting TZ to EST or UTC
>>>> worked and specifying IST at the end of the
>>>> timestamp worked, but setting TZ to IST
>>>> failed just like it does in gawk. Clearly I'm
>>>> missing something...

>>> All of this depends on the underlying C
>>> library.  As far as I know there aren't
>>> standardized time zone names that work the
>>> same everywhere.

>> Actually, there are, at least in most practical
>> cases.  But they are very few, and you cannot
>> rely on their DST rules to be up to date with
>> the current practices; they might on some
>> systems still reflect the DST rules of many
>> years ago, or even work according to the rules
>> of another country.

> FWIW I found some information on "standard" time
  zones: [...]

> Thanks for the feedback all, looks like gawk
> behaves the same as date wrt TZ environment
> values so there's no gawk issue.

As you've seen, date(1) is pretty good at recognizing dates[*], including time 
zones, in arguments supplied via the -d option.

I make an external call to date(1), instead of mktime(), when I can't be sure 
that the input is well-behaved.  I'm sure it's more expensive then mktime(), 
but the overhead seems a tolerable price to pay when compared to the 
alternatives of parsing the date string, trying to maintain a table of time 
zone offsets, or explicitly consulting the system's time zone database.

Something like this:

  returncode = ( ( "date -d  " datearg " +%s" ) | getline dateresult )

(Simplified to show the concept.  I have a wrapper function that escapes the 
arguments to date(1), checks the returncode, and call close().)



[*] At least on systems that have the GNU core utilities date.