From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13454 Path: news.gmane.org!.POSTED!not-for-mail From: Bartosz Brachaczek Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: [PATCH libc-test] add strptime basic test Date: Fri, 16 Nov 2018 22:21:01 +0100 Message-ID: References: <20181115073456.11105-1-zajec5@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000243833057acebf3a" X-Trace: blaine.gmane.org 1542403161 912 195.159.176.226 (16 Nov 2018 21:19:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Nov 2018 21:19:21 +0000 (UTC) Cc: rafal@milecki.pl To: musl@lists.openwall.com Original-X-From: musl-return-13470-gllmg-musl=m.gmane.org@lists.openwall.com Fri Nov 16 22:19:16 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gNlWG-00008U-Hw for gllmg-musl@m.gmane.org; Fri, 16 Nov 2018 22:19:16 +0100 Original-Received: (qmail 26433 invoked by uid 550); 16 Nov 2018 21:21:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 26385 invoked from network); 16 Nov 2018 21:21:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g0D48P/0j4mqOOOfjFz3EO40TZ3lzB3mHmXu1lvxAVU=; b=qLeYSWG1wNtJfFZ7dQdW+pz4aVsAzmN/VomOwCBGCUISZLoXCDJrTfUqyx9gKTw+ZV QbtUhBivVbELqg8WZpkbnThceuRuyVeMOK86KXc40/gIAqaaI09CmgL7VNGy1fi0hIg4 VrK6kOAX9NHiS+JUusbmuAjIHWZmGF1p0M+iwjJREKuIphRK2gzdbfBBQa0lCYWjnS3m 2A2tJ9fx6RuDdCcvr0zEmtc/jPOW04DM9nOAHa9ESgCDoWoBvNnu5UWrBxxKc/kaMP7S hDujM8tZeFKdfHuhp7xEGpwZKFP0lQVXMKGEXxxom9hlchmruNnJwyC1upNE6oDrwzqx wy+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g0D48P/0j4mqOOOfjFz3EO40TZ3lzB3mHmXu1lvxAVU=; b=dQartmTIhRyHB//LI8Qt2PFkpMm2x4Jil2W29jutTOWYaaGiVwTy2IbGCx4V++RrKj 6uA2YlrzWYQSt4rDj/HXHP0VNWZF9fZ1uD0ir1iU80Pr3+mfNUOhj/IL7c/JshRyflCd zCGiBDFUe6VRqUPsk+rQYkcWLkJM2yHsckLN/0KX5zLmHJPwZ9xCLBhLvQninc1j6qm2 DGA0xV+Z5lVm6sqm7sp090+Fl7fr2qSUzlu10FjF7bvFjq5eKbwOWTbritxKPyEnxUs2 ut06S2qIksESr6M4RMjM1ItPtdpKXAjzjDl/jXQczh/VbtcHcSu8LjyO14oFutYEPhZi QkbQ== X-Gm-Message-State: AGRZ1gL+gJD4wV72c9L35Aby79ZX6lgtHXstzxaUUGv6ygyhS9OZdOih IFLcXVaDO/hnl7Gi8kAa+0AnbJirb+LBZ/UotBnyhrRR X-Google-Smtp-Source: AJdET5c4sdeSek86D2XdZHR1/cpQIbbeyAMzsdxt/Lju/xAuX+Se8o3nMcNTc1Os0oLDbfGuAjsXC+1Jkt5ZxSdBvnw= X-Received: by 2002:aca:edc3:: with SMTP id l186-v6mr1995241oih.351.1542403272225; Fri, 16 Nov 2018 13:21:12 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:13454 Archived-At: --000000000000243833057acebf3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 15, 2018 at 11:12 AM Rafa=C5=82 Mi=C5=82ecki = wrote: > On 15.11.2018 08:34, Rafa=C5=82 Mi=C5=82ecki wrote: > > From: Rafa=C5=82 Mi=C5=82ecki > > > > Signed-off-by: Rafa=C5=82 Mi=C5=82ecki > > I've just tried it with musl (I should have done that before sending a > patch) and noticed is fails with: > > "%Y-%m-%d": for "1991-08-25" expected 1991-08-25T00:00:00 (day 237: Sun) > but got 1991-08-25T00:00:00 (day 001: Sun) > "%d.%m.%y": for "25.08.91" expected 1991-08-25T00:00:00 (day 237: Sun) bu= t > got 1991-08-25T00:00:00 (day 001: Sun) > "%D": for "08/25/91" expected 1991-08-25T00:00:00 (day 237: Sun) but got > 1991-08-25T00:00:00 (day 001: Sun) > "%d.%m.%y": for "21.10.15" expected 2015-10-21T00:00:00 (day 294: Wed) bu= t > got 2015-10-21T00:00:00 (day 001: Sun) > "%d.%m.%y in %C th": for "10.7.56 in 18th" expected 1856-07-10T00:00:00 > (day 192: Thu) but got 1856-07-10T00:00:00 (day 001: Sun) > > which I didn't expect. > > It's because I assumed glibc behavior which sets tm_wday and tm_yday. > > The man says: > "In principle, this function does not initialize tm but stores only the > values specified." > > There is a glibc behavior however: > "Details differ a bit between different UNIX sys-tems. The glibc > implementation does not touch those fields which are not explicitly > specified, except that it recomputes the tm_wday and tm_yday field if > any of the year, month, or day elements changed." > > I guess a correct test should allow any behavior and don't test tm_wday > and tm_yday fields. > > > It also fails with: > > "%F": failed to parse "1856-07-10" > "%s": failed to parse "683078400" > "%z": failed to parse "+0200" > "%z": failed to parse "-0530" > "%z": failed to parse "-06" > > but that's expected due to unimplemented %F %s and %z. > I cannot find anything in the normative text that would suggest that recomputing tm_wday and/or tm_yday is required, but interestingly enough, the strptime example that is used in POSIX seems to rely on that. See: https://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html. That example does not produce expected output using musl. Possibly something that should be clarified in POSIX? --000000000000243833057acebf3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 15, 2018 at 11:12 AM Rafa=C5= =82 Mi=C5=82ecki <= zajec5@gmail.com> wrote:
On 15.11.2018 08:34, Rafa=C5=82 Mi=C5=82ecki wrote:=
> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>
> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>

I've just tried it with musl (I should have done that before sending a<= br> patch) and noticed is fails with:

"%Y-%m-%d": for "1991-08-25" expected 1991-08-25T00:00:= 00 (day 237: Sun) but got 1991-08-25T00:00:00 (day 001: Sun)
"%d.%m.%y": for "25.08.91" expected 1991-08-25T00:00:00= (day 237: Sun) but got 1991-08-25T00:00:00 (day 001: Sun)
"%D": for "08/25/91" expected 1991-08-25T00:00:00 (day = 237: Sun) but got 1991-08-25T00:00:00 (day 001: Sun)
"%d.%m.%y": for "21.10.15" expected 2015-10-21T00:00:00= (day 294: Wed) but got 2015-10-21T00:00:00 (day 001: Sun)
"%d.%m.%y in %C th": for "10.7.56 in 18th" expected 185= 6-07-10T00:00:00 (day 192: Thu) but got 1856-07-10T00:00:00 (day 001: Sun)<= br>
which I didn't expect.

It's because I assumed glibc behavior which sets tm_wday and tm_yday.
The man says:
"In principle, this function does not initialize tm but stores only th= e
values specified."

There is a glibc behavior however:
"Details differ a bit between different UNIX sys-tems.=C2=A0 The glibc=
implementation does not touch those fields which are not explicitly
specified, except that it recomputes the tm_wday and tm_yday field if
any of the year, month,=C2=A0 or=C2=A0 day=C2=A0 elements changed."
I guess a correct test should allow any behavior and don't test tm_wday=
and tm_yday fields.


It also fails with:

"%F": failed to parse "1856-07-10"
"%s": failed to parse "683078400"
"%z": failed to parse "+0200"
"%z": failed to parse "-0530"
"%z": failed to parse "-06"

but that's expected due to unimplemented %F %s and %z.
=

I cannot find anything in the normative text that would= suggest that recomputing tm_wday and/or tm_yday is required, but interesti= ngly enough, the strptime example that is used in POSIX seems to rely on th= at. See:=C2=A0https://pubs.opengroup.org/online= pubs/9699919799/functions/strptime.html. That example does not produce = expected output using musl.

Possibly something tha= t should be clarified in POSIX?
--000000000000243833057acebf3a--