Hello,

On 2018-10-15 8:11 a.m., Assaf Gordon wrote:
> tags 9614 wontfix
> severity 9614 wishlist

Changed my mind (and noticed that Paul removed the "wontfix" tag),
so here goes...


> On 27/09/11 11:48 PM, Paul Eggert wrote:
>> On 09/27/11 22:44, Sandro Santilli wrote:
>>> A warning/error message with hint on how to correctly form
>>> the string would be very friendly for users
>>
>> Unfortunately, there's no portable way to determine
>> which TZ values are supported on the current platform.
>> One cannot even reliably determine whether the current TZ
>> value is supported.  So it's not clear how that warning
>> would be generated.
>>

Attached is a crude attempt at detecting and warning about invalid
timezone strings.

First and foremost,
the code only runs when the user specify "--debug", so hopefully it
won't have any ill effects.

Second,
the goal is to detect the most common usage errors (e.g.
"America/NewYorx" or "Jamaika"), not to re-implement a fool-proof parser
for timezones.

Third,
The code runs "mostly well" on "most common" operating systems.
There sure to be cases where it doesn't work (but the "doesn't work"
part simply means that with "--debug" it might warn about invalid
timezone when it is a valid timezone that resolves to GMT).
OpenBSD is such a case.

---

With this patch, "date --debug" is able to warn about:

    TZ=America/NewYorx date --debug
    TZ=Europe/Lomdom date --debug
    TZ=FOOBAR date --debug
    date --debug -d 'TZ="Asia/Japan" 2019-01-01'

while it knows not to warn about:

    TZ=Africa/Dakar date --debug   # Valid GMT timezone
    TZ=GB date --debug             # Valid GMT timezone on most systems
    TZ=FOO+0 date --debug          # Valid UTC+0 timezone

The warning looks like so:

    $ TZ=America/Kalgary ./src/date --debug
    date: possibly invalid timezone in TZ envvar:
    date:    ‘America/Kalgary’
    date: timezone UTC0 will be used.
    Mon Dec 31 16:41:08 America 2018

The detection works well on Debian 9, Centos 7,
FreeBSD 11, NetBSD 7.1, AIX 7.2 .

OpenBSD is an example of where it doesn't work - there's no way
to differentiate between an invalid timezone and a valid GMT timezone.
But on such system, the code self-diagnoses this issue and prints
additional warnings:

   $ TZ=Africa/Dakar ./src/date --debug
   date: possibly invalid timezone in TZ envvar:
   date:    'Africa/Dakar'
   date: timezone UTC0 will be used.
   date: this system has limited capabilities in detecting
   date: invalid timezones. It is possible this is a valid timezone
   date: in the GMT zone.
   Mon Dec 31 16:43:35 GMT 2018

---

This patch includes a unit-test, but because the names of available
timezones vary so much between systems, it doesn't pass everywhere.
It is therefore marked as "very expensive".

To run it, use:

     make check SUBDIRS=. TESTS=tests/misc/date-debug-TZ.pl \
                RUN_VERY_EXPENSIVE_TESTS=yes

---

The heuristic code to determine if a timezone is valid or not is quite
hairy. There's likely room for improvements.


Comments and feedback and improvement suggestions are welcomed,
  - assaf