Re: [bug #21455] date --date "" "+test" fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

[Jim Meyering]

Philip Rowlands <address@hidden> wrote:
...
> $ zdump -v Europe/Paris
> Europe/Paris  Sun Oct 28 00:59:59 2007 UTC = Sun Oct 28 02:59:59 2007 CEST 
> isdst=1 gmtoff=7200
> Europe/Paris  Sun Oct 28 01:00:00 2007 UTC = Sun Oct 28 02:00:00 2007 CET 
> isdst=0 gmtoff=3600
>
> In Europe/Paris, the boundaries of "invalid" times are 1193533200 ->
> 1193612399 inclusive, or
> Sun Oct 28 02:00:00 CET 2007 -> Sun Oct 28 23:59:59 CET 2007
...
> This corresponds to the first second of winter time "isdst=0" and
> persists for the rest of the logical day. I'm wary about diving around
> in unfamiliar code - perhaps someone more familiar with date parsing
> knows how date -d "" is supposed to be treated, and what the problem
> is here?

Hi Phil,

I'm hardly the authority on such TZ things, but would have thought
the invalid zones are those two intervals (one per line), which
are nominally two and one hours long.  It looks like they're two
different views of the same two-real-hour interval.  The first uses
the DST (isdst=1) times, and the second non-DST times.

Date's -d option interprets an empty string just like "0",
which is interpreted as 00:00 in the current day.

This is already documented:

    $ grep empt getdate.texi
    A @dfn{date} is a string, possibly empty, containing many items
    ambiguity arises.  The empty string means the beginning of today (i.e.,

Or, in "info coreutils date general"

    27.1 General date syntax
    ========================

    A "date" is a string, possibly empty, containing many items separated
    by whitespace.  The whitespace may be omitted when no ambiguity arises.
    The empty string means the beginning of today (i.e., midnight).  Order