[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 May 2019 14:23:39 -0400
From: Rich Felker <dalias@...c.org>
To: Niklas Hambüchen <mail@....me>
Cc: coreutils@....org, mjbauer95@...il.com, musl@...ts.openwall.com
Subject: Re: date-debug test failure with musl
On Mon, May 13, 2019 at 05:02:48AM +0200, Niklas Hambüchen wrote:
> Dear coreutils maintainers,
>
> when compiling coreutils commit 6e97d36 against musl v1.1.22 on Ubuntu, I get a test failure and differing output than when using glibc.
>
> Running `src/date --debug -d 'TZ="America/Edmonton" 2006-04-02 02:30:00'` with each:
>
> With glibc it prints:
>
> date: normalized time: '(Y-M-D) 2006-04-02 03:30:00'
>
> With musl it prints:
>
> date: normalized time: '(Y-M-D) 2006-04-02 01:30:00'`
>
> This difference results in tests/misc/date-debug to fail.
>
> What's happening here? Is there a bug in musl, or some quirks going on?
> Any insight would be appreciated.
The requested time is right in the middle of the "leap forward" DST
transition; no such time exists. As I understand, it's been requested
from mktime with tm_isdst<0 to "cause mktime() to attempt to determine
whether Daylight Savings Time is in effect for the specified time."
The standard provides no definition for "attempt" or what should
happen if such an attempt fails due to ambiguity or nonexistence, and
I don't see any fundamental reason to prefer the glibc or musl result
here. One is more natural working backwards from 3am; the other is
more natural working forwards from 1:59:59am.
As long as coreutils' date is producing the desired "invalid" error
either way, which it seems to be, I think it's a mistake that the
debug output for "normalized time" is being compared as part of the
test assertion. Only the result should matter, not the path by which
it's reached.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
