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
