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.