Hi,

Posting on bug-gnulib since this test failure seems to be caused by
parse-datetime despite being caught by tests/date/date-debug.sh in
Coreutils.

On NetBSD 10.0 (cfarm428.cfarm.net) it fails with the following:

    + returns_ 1 date --debug -d 'TZ="America/Edmonton" 2006-04-02 02:30:00'
    + sed '/normalized time:/s/ [0-9][0-9]:[0-9][0-9]:[0-9][0-9]/ XX:XX:XX/' 
out2-t
    [...]
    + diff -u exp2 out2
    --- exp2    2025-06-08 23:56:08.721418060 +0000
    +++ out2    2025-06-08 23:56:08.761007453 +0000
    @@ -5,9 +5,8 @@
     date: error: invalid date/time value:
     date:     user provided time: '(Y-M-D) 2006-04-02 02:30:00'
     date:        normalized time: '(Y-M-D) 2006-04-02 XX:XX:XX'
    -date:                                             --
    +date: 
     date:      possible reasons:
    -date:        nonexistent due to daylight-saving time;
     date:        numeric values overflow;
     date:        missing timezone
     date: invalid date 'TZ="America/Edmonton" 2006-04-02 02:30:00'

So, on NetBSD this time is not properly recognized as being non-existent
due to daylight-savings time changes. I have confirmed that
'zdump -v America/Edmonton | grep 2006' is the same as on GNU/Linux, so
I assume this is a bug in parse-datetime or the systems time functions.

Specifically, it seems that 'mktime_ok' returns the correct value but
'dst_shift' in 'debug_mktime_not_ok' is set incorrectly:

      const bool eq_hour  = (tm0->tm_hour == tm1->tm_hour);
      [...]
      const bool dst_shift = eq_sec && eq_min && !eq_hour
                             && eq_mday && eq_month && eq_year;

Running the command outside of the test-suite shows the issue:

    ./src/date --debug -d 'TZ="America/Edmonton" 2006-04-02 02:30:00'
    [...]
    date:     user provided time: '(Y-M-D) 2006-04-02 02:30:00'
    date:        normalized time: '(Y-M-D) 2006-04-02 02:30:00'
    [...]

The value of 'eq_hour' is true when it should be false, which then sets
'dst_shift' incorrectly.

Paul, do you know what the correct fix is for this? You certainly know
the time functions better than me.

Collin

Reply via email to