Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 May 2019 14:23:39 -0400
From: Rich Felker <>
To: Niklas Hamb├╝chen <>
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.


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.