X-Loop: help-debbugs@HIDDEN
Subject: bug#18328: can't say date -d '8pm -0500' though other combos work
Resent-From: =?UTF-8?Q?=E7=A9=8D=E4=B8=B9=E5=B0=BC?= Dan Jacobson <jidanni@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Mon, 25 Aug 2014 16:02:01 +0000
Resent-Message-ID: <handler.18328.B.14089825184286 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 18328
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords:
To: 18328 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-coreutils@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.14089825184286
(code B ref -1); Mon, 25 Aug 2014 16:02:01 +0000
Received: (at submit) by debbugs.gnu.org; 25 Aug 2014 16:01:58 +0000
Received: from localhost ([127.0.0.1]:51894 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1XLwiQ-00016z-2w
for submit <at> debbugs.gnu.org; Mon, 25 Aug 2014 12:01:57 -0400
Received: from eggs.gnu.org ([208.118.235.92]:59274)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <jidanni@HIDDEN>) id 1XLwiJ-00016U-TX
for submit <at> debbugs.gnu.org; Mon, 25 Aug 2014 12:01:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <jidanni@HIDDEN>) id 1XLwi6-0003RJ-K0
for submit <at> debbugs.gnu.org; Mon, 25 Aug 2014 12:01:42 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level:
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,T_DKIM_INVALID
autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:48828)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <jidanni@HIDDEN>) id 1XLwi6-0003RD-HD
for submit <at> debbugs.gnu.org; Mon, 25 Aug 2014 12:01:34 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60931)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <jidanni@HIDDEN>) id 1XLwhz-0006te-Lh
for bug-coreutils@HIDDEN; Mon, 25 Aug 2014 12:01:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <jidanni@HIDDEN>) id 1XLwhs-0003NY-MG
for bug-coreutils@HIDDEN; Mon, 25 Aug 2014 12:01:27 -0400
Received: from homie.mail.dreamhost.com ([208.97.132.208]:49202
helo=homiemail-a8.g.dreamhost.com)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from <jidanni@HIDDEN>) id 1XLwhs-0003MW-Gt
for bug-coreutils@HIDDEN; Mon, 25 Aug 2014 12:01:20 -0400
Received: from homiemail-a8.g.dreamhost.com (localhost [127.0.0.1])
by homiemail-a8.g.dreamhost.com (Postfix) with ESMTP id AA8F1D22088
for <bug-coreutils@HIDDEN>; Mon, 25 Aug 2014 09:01:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jidanni.org; h=from:to
:subject:date:message-id:mime-version:content-type:
content-transfer-encoding; s=jidanni.org; bh=qdXurzIiAnbEZzT4d4M
rJYVHdfs=; b=ZlKEDKqxfoGCiS86Kt8+q4VtDT9HRxJtQWKxk2XEd335yxwUWLd
JGsA+omLammFncJKm7YTGqxssD6XtE57gAYHsFx90qv7ZFcb+adcOkvXEhbosRwc
8XUnyUEPDC+rIbJe7MzATlIRgihDfbBIy/E/6Ge9BKrvY5jAF/kcy+Pw=
Received: from jidanni.org (111-246-102-246.dynamic.hinet.net
[111.246.102.246])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: jidanni@HIDDEN)
by homiemail-a8.g.dreamhost.com (Postfix) with ESMTPSA id 5AFC4D22082
for <bug-coreutils@HIDDEN>; Mon, 25 Aug 2014 09:01:18 -0700 (PDT)
From: =?UTF-8?Q?=E7=A9=8D=E4=B8=B9=E5=B0=BC?= Dan Jacobson <jidanni@HIDDEN>
Date: Tue, 26 Aug 2014 00:01:16 +0800
Message-ID: <87ppfo36er.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no
timestamps) [generic]
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
(bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)
$ date -d '8pm -0500'
date: invalid date =E2=80=988pm -0500=E2=80=99 <--why can't this combo wo=
rk?
$ date -d '20:00 -0500'
=E4=BA=8C 8=E6=9C=88 26 09:00:00 CST 2014
$ date -d 'sun 8pm'
=E6=97=A5 8=E6=9C=88 31 20:00:00 CST 2014
$ date -d '8pm'
=E4=B8=80 8=E6=9C=88 25 20:00:00 CST 2014
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: =?UTF-8?Q?=E7=A9=8D=E4=B8=B9=E5=B0=BC?= Dan Jacobson <jidanni@HIDDEN> Subject: bug#18328: Acknowledgement (can't say date -d '8pm -0500' though other combos work) Message-ID: <handler.18328.B.14089825184286.ack <at> debbugs.gnu.org> References: <87ppfo36er.fsf@HIDDEN> X-Gnu-PR-Message: ack 18328 X-Gnu-PR-Package: coreutils Reply-To: 18328 <at> debbugs.gnu.org Date: Mon, 25 Aug 2014 16:02:02 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): bug-coreutils@HIDDEN If you wish to submit further information on this problem, please send it to 18328 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 18328: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18328 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN
Subject: bug#18328: can't say date -d '8pm -0500' though other combos work
Resent-From: Assaf Gordon <assafgordon@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Sat, 20 Oct 2018 04:26:02 +0000
Resent-Message-ID: <handler.18328.B18328.154000951211855 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 18328
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords:
To: =?UTF-8?Q?=E7=A9=8D=E4=B8=B9=E5=B0=BC?= Dan Jacobson <jidanni@HIDDEN>, 18328 <at> debbugs.gnu.org
Received: via spool by 18328-submit <at> debbugs.gnu.org id=B18328.154000951211855
(code B ref 18328); Sat, 20 Oct 2018 04:26:02 +0000
Received: (at 18328) by debbugs.gnu.org; 20 Oct 2018 04:25:12 +0000
Received: from localhost ([127.0.0.1]:60173 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gDip6-000354-K6
for submit <at> debbugs.gnu.org; Sat, 20 Oct 2018 00:25:12 -0400
Received: from mail-pl1-f181.google.com ([209.85.214.181]:41287)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <assafgordon@HIDDEN>)
id 1gDip4-00034k-ER; Sat, 20 Oct 2018 00:25:10 -0400
Received: by mail-pl1-f181.google.com with SMTP id p5-v6so1772218plq.8;
Fri, 19 Oct 2018 21:25:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-language:content-transfer-encoding;
bh=RWs7K0jLeE2LOJnTqwfe3ComoQfxwOo+AeRg966eW9c=;
b=OFy5sH78wMdt5lDH77biehinFLdFxt+gurZwR6Kc8HkKICMIcqnLTl7OnG8WY7kYWi
CklRj00/NWO8cz8s7Il9e9TmRuavgP+QjRWqO//giST1KFS2n9qdw0cjrJlB+f6n7mmQ
VgTfK8bHh83B9LaV8JJwkaf5KOuXtAGBX0ij4RYQih8/O3wzH33vWIqNnjadBEDsnTpJ
4bPJMznIfp5a1huS4HQFD3o2G2Wew5vMqP5z5/Ifun9qUOGgw6lUx/awyfzoWJNCAxhZ
8hjP56IVo97fGREbsHSCzh3GFVHykC4j0J2FxUYQ77+0FnGZQ4Cgsd78H8hzt9XMRqJ9
nQKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:message-id:date
:user-agent:mime-version:in-reply-to:content-language
:content-transfer-encoding;
bh=RWs7K0jLeE2LOJnTqwfe3ComoQfxwOo+AeRg966eW9c=;
b=hJm91wvHi++plC6epKcPejWNmG8zuHbMrdYeZzOFUwWptnc9AIX2CM4dbdW5DhtAId
D//PA1PfEx8J7dqXKbs8ZPCvN8xdzzrVBEBBYUnB4T1xHT1RJP/SA/DmVsTs3ONvZ6DE
fNT14Knuy8hZIjkkIDlEA+QK9s09qNk/YVzb2OCkzGzZ/FJBBe0pZx6gthvqUIAII5pA
b9+6i4YHSJDZXl0C1+yUeG+NYVW39GmCa5voQf2IzE/xNAWXKBPkLFUpuEoEtcOEi7Ru
tn3HhWoJacJtyZZAToGxT2hiP9kR6/ISBm8vx+BP6kxh4M91lG1IvtERDHHfnkjXB9WT
+llA==
X-Gm-Message-State: ABuFfohyJbYjqyu3gl8RdrVpW0Jl8f5eexjCD8oOzah6u0B5XkW/FyEN
WgBJlOTuIdA3EQqCcRnp3EffAGrGbo0=
X-Google-Smtp-Source: ACcGV60IqJ96xHOUzI4qgG82B27Hbm/JLGyPuJx3rIF4W4JCKOF+hY8+eEeU5RNA08CH85wBiuiHfA==
X-Received: by 2002:a17:902:2b84:: with SMTP id
l4-v6mr12471171plb.124.1540009503858;
Fri, 19 Oct 2018 21:25:03 -0700 (PDT)
Received: from tomato.housegordon.com (moose.housegordon.com. [184.68.105.38])
by smtp.googlemail.com with ESMTPSA id
l129-v6sm33959759pfc.155.2018.10.19.21.25.01
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 19 Oct 2018 21:25:02 -0700 (PDT)
References: <87ppfo36er.fsf@HIDDEN>
From: Assaf Gordon <assafgordon@HIDDEN>
Message-ID: <c8968416-98b5-74ba-ffbe-cd49a23b173c@HIDDEN>
Date: Fri, 19 Oct 2018 22:25:00 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <87ppfo36er.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
tags 18328 confirmed
retitle 18328 date: '8pm -0500' is invalid (am/pm problem)
stop
(triaging old bugs)
Hello,
On 25/08/14 10:01 AM, 積丹尼 Dan Jacobson wrote:
> $ date -d '8pm -0500'
> date: invalid date ‘8pm -0500’ <--why can't this combo work?
This is indeed a bug (specifically in gnulib's date parsing module,
but easier to track here).
It seems the existence of the "am/pm" string causes the parser
to take a slightly different rule, then reject additional relative
values, unless they have a unit, e.g.:
$ date --debug -d '8pm +5 days'
date: parsed time part: 08:00:00pm
date: parsed relative part: +5 day(s)
[...]
Contrast it with a different (and confusing) rules when there is
no "am/pm", the relative number is always taken as the time zone, e.g.:
$ date --debug -d '8:00 +5 days'
date: parsed time part: 08:00:00 UTC+05
date: parsed relative part: +1 day(s)
date: input timezone: parsed date/time string (+05)
[...]
(from https://bugs.gnu.org/17161#31 )
I hope to get to this bug soon.
-assaf
Received: (at control) by debbugs.gnu.org; 20 Oct 2018 04:25:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 20 00:25:12 2018 Received: from localhost ([127.0.0.1]:60171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gDip6-000352-BE for submit <at> debbugs.gnu.org; Sat, 20 Oct 2018 00:25:12 -0400 Received: from mail-pl1-f181.google.com ([209.85.214.181]:41287) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <assafgordon@HIDDEN>) id 1gDip4-00034k-ER; Sat, 20 Oct 2018 00:25:10 -0400 Received: by mail-pl1-f181.google.com with SMTP id p5-v6so1772218plq.8; Fri, 19 Oct 2018 21:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RWs7K0jLeE2LOJnTqwfe3ComoQfxwOo+AeRg966eW9c=; b=OFy5sH78wMdt5lDH77biehinFLdFxt+gurZwR6Kc8HkKICMIcqnLTl7OnG8WY7kYWi CklRj00/NWO8cz8s7Il9e9TmRuavgP+QjRWqO//giST1KFS2n9qdw0cjrJlB+f6n7mmQ VgTfK8bHh83B9LaV8JJwkaf5KOuXtAGBX0ij4RYQih8/O3wzH33vWIqNnjadBEDsnTpJ 4bPJMznIfp5a1huS4HQFD3o2G2Wew5vMqP5z5/Ifun9qUOGgw6lUx/awyfzoWJNCAxhZ 8hjP56IVo97fGREbsHSCzh3GFVHykC4j0J2FxUYQ77+0FnGZQ4Cgsd78H8hzt9XMRqJ9 nQKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RWs7K0jLeE2LOJnTqwfe3ComoQfxwOo+AeRg966eW9c=; b=hJm91wvHi++plC6epKcPejWNmG8zuHbMrdYeZzOFUwWptnc9AIX2CM4dbdW5DhtAId D//PA1PfEx8J7dqXKbs8ZPCvN8xdzzrVBEBBYUnB4T1xHT1RJP/SA/DmVsTs3ONvZ6DE fNT14Knuy8hZIjkkIDlEA+QK9s09qNk/YVzb2OCkzGzZ/FJBBe0pZx6gthvqUIAII5pA b9+6i4YHSJDZXl0C1+yUeG+NYVW39GmCa5voQf2IzE/xNAWXKBPkLFUpuEoEtcOEi7Ru tn3HhWoJacJtyZZAToGxT2hiP9kR6/ISBm8vx+BP6kxh4M91lG1IvtERDHHfnkjXB9WT +llA== X-Gm-Message-State: ABuFfohyJbYjqyu3gl8RdrVpW0Jl8f5eexjCD8oOzah6u0B5XkW/FyEN WgBJlOTuIdA3EQqCcRnp3EffAGrGbo0= X-Google-Smtp-Source: ACcGV60IqJ96xHOUzI4qgG82B27Hbm/JLGyPuJx3rIF4W4JCKOF+hY8+eEeU5RNA08CH85wBiuiHfA== X-Received: by 2002:a17:902:2b84:: with SMTP id l4-v6mr12471171plb.124.1540009503858; Fri, 19 Oct 2018 21:25:03 -0700 (PDT) Received: from tomato.housegordon.com (moose.housegordon.com. [184.68.105.38]) by smtp.googlemail.com with ESMTPSA id l129-v6sm33959759pfc.155.2018.10.19.21.25.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Oct 2018 21:25:02 -0700 (PDT) Subject: Re: bug#18328: can't say date -d '8pm -0500' though other combos work To: =?UTF-8?B?56mN5Li55bC8IERhbiBKYWNvYnNvbg==?= <jidanni@HIDDEN>, 18328 <at> debbugs.gnu.org References: <87ppfo36er.fsf@HIDDEN> From: Assaf Gordon <assafgordon@HIDDEN> Message-ID: <c8968416-98b5-74ba-ffbe-cd49a23b173c@HIDDEN> Date: Fri, 19 Oct 2018 22:25:00 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87ppfo36er.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) tags 18328 confirmed retitle 18328 date: '8pm -0500' is invalid (am/pm problem) stop (triaging old bugs) Hello, On 25/08/14 10:01 AM, 積丹尼 Dan Jacobson wrote: > $ date -d '8pm -0500' > date: invalid date ‘8pm -0500’ <--why can't this combo work? This is indeed a bug (specifically in gnulib's date parsing module, but easier to track here). It seems the existence of the "am/pm" string causes the parser to take a slightly different rule, then reject additional relative values, unless they have a unit, e.g.: $ date --debug -d '8pm +5 days' date: parsed time part: 08:00:00pm date: parsed relative part: +5 day(s) [...] Contrast it with a different (and confusing) rules when there is no "am/pm", the relative number is always taken as the time zone, e.g.: $ date --debug -d '8:00 +5 days' date: parsed time part: 08:00:00 UTC+05 date: parsed relative part: +1 day(s) date: input timezone: parsed date/time string (+05) [...] (from https://bugs.gnu.org/17161#31 ) I hope to get to this bug soon. -assaf
Received: (at control) by debbugs.gnu.org; 20 Oct 2018 04:25:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 20 00:25:12 2018 Received: from localhost ([127.0.0.1]:60171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gDip6-000352-BE for submit <at> debbugs.gnu.org; Sat, 20 Oct 2018 00:25:12 -0400 Received: from mail-pl1-f181.google.com ([209.85.214.181]:41287) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <assafgordon@HIDDEN>) id 1gDip4-00034k-ER; Sat, 20 Oct 2018 00:25:10 -0400 Received: by mail-pl1-f181.google.com with SMTP id p5-v6so1772218plq.8; Fri, 19 Oct 2018 21:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RWs7K0jLeE2LOJnTqwfe3ComoQfxwOo+AeRg966eW9c=; b=OFy5sH78wMdt5lDH77biehinFLdFxt+gurZwR6Kc8HkKICMIcqnLTl7OnG8WY7kYWi CklRj00/NWO8cz8s7Il9e9TmRuavgP+QjRWqO//giST1KFS2n9qdw0cjrJlB+f6n7mmQ VgTfK8bHh83B9LaV8JJwkaf5KOuXtAGBX0ij4RYQih8/O3wzH33vWIqNnjadBEDsnTpJ 4bPJMznIfp5a1huS4HQFD3o2G2Wew5vMqP5z5/Ifun9qUOGgw6lUx/awyfzoWJNCAxhZ 8hjP56IVo97fGREbsHSCzh3GFVHykC4j0J2FxUYQ77+0FnGZQ4Cgsd78H8hzt9XMRqJ9 nQKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RWs7K0jLeE2LOJnTqwfe3ComoQfxwOo+AeRg966eW9c=; b=hJm91wvHi++plC6epKcPejWNmG8zuHbMrdYeZzOFUwWptnc9AIX2CM4dbdW5DhtAId D//PA1PfEx8J7dqXKbs8ZPCvN8xdzzrVBEBBYUnB4T1xHT1RJP/SA/DmVsTs3ONvZ6DE fNT14Knuy8hZIjkkIDlEA+QK9s09qNk/YVzb2OCkzGzZ/FJBBe0pZx6gthvqUIAII5pA b9+6i4YHSJDZXl0C1+yUeG+NYVW39GmCa5voQf2IzE/xNAWXKBPkLFUpuEoEtcOEi7Ru tn3HhWoJacJtyZZAToGxT2hiP9kR6/ISBm8vx+BP6kxh4M91lG1IvtERDHHfnkjXB9WT +llA== X-Gm-Message-State: ABuFfohyJbYjqyu3gl8RdrVpW0Jl8f5eexjCD8oOzah6u0B5XkW/FyEN WgBJlOTuIdA3EQqCcRnp3EffAGrGbo0= X-Google-Smtp-Source: ACcGV60IqJ96xHOUzI4qgG82B27Hbm/JLGyPuJx3rIF4W4JCKOF+hY8+eEeU5RNA08CH85wBiuiHfA== X-Received: by 2002:a17:902:2b84:: with SMTP id l4-v6mr12471171plb.124.1540009503858; Fri, 19 Oct 2018 21:25:03 -0700 (PDT) Received: from tomato.housegordon.com (moose.housegordon.com. [184.68.105.38]) by smtp.googlemail.com with ESMTPSA id l129-v6sm33959759pfc.155.2018.10.19.21.25.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Oct 2018 21:25:02 -0700 (PDT) Subject: Re: bug#18328: can't say date -d '8pm -0500' though other combos work To: =?UTF-8?B?56mN5Li55bC8IERhbiBKYWNvYnNvbg==?= <jidanni@HIDDEN>, 18328 <at> debbugs.gnu.org References: <87ppfo36er.fsf@HIDDEN> From: Assaf Gordon <assafgordon@HIDDEN> Message-ID: <c8968416-98b5-74ba-ffbe-cd49a23b173c@HIDDEN> Date: Fri, 19 Oct 2018 22:25:00 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87ppfo36er.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) tags 18328 confirmed retitle 18328 date: '8pm -0500' is invalid (am/pm problem) stop (triaging old bugs) Hello, On 25/08/14 10:01 AM, 積丹尼 Dan Jacobson wrote: > $ date -d '8pm -0500' > date: invalid date ‘8pm -0500’ <--why can't this combo work? This is indeed a bug (specifically in gnulib's date parsing module, but easier to track here). It seems the existence of the "am/pm" string causes the parser to take a slightly different rule, then reject additional relative values, unless they have a unit, e.g.: $ date --debug -d '8pm +5 days' date: parsed time part: 08:00:00pm date: parsed relative part: +5 day(s) [...] Contrast it with a different (and confusing) rules when there is no "am/pm", the relative number is always taken as the time zone, e.g.: $ date --debug -d '8:00 +5 days' date: parsed time part: 08:00:00 UTC+05 date: parsed relative part: +1 day(s) date: input timezone: parsed date/time string (+05) [...] (from https://bugs.gnu.org/17161#31 ) I hope to get to this bug soon. -assaf
X-Loop: help-debbugs@HIDDEN
Subject: bug#18328: can't say date -d '8pm -0500' though other combos work
In-Reply-To: <87ppfo36er.fsf@HIDDEN>
Resent-From: =?UTF-8?Q?=E7=A9=8D=E4=B8=B9=E5=B0=BC?= Dan Jacobson <jidanni@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Sat, 20 Oct 2018 06:31:02 +0000
Resent-Message-ID: <handler.18328.B18328.154001703431205 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 18328
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: confirmed
To: Assaf Gordon <assafgordon@HIDDEN>
Cc: 18328 <at> debbugs.gnu.org
Received: via spool by 18328-submit <at> debbugs.gnu.org id=B18328.154001703431205
(code B ref 18328); Sat, 20 Oct 2018 06:31:02 +0000
Received: (at 18328) by debbugs.gnu.org; 20 Oct 2018 06:30:34 +0000
Received: from localhost ([127.0.0.1]:60188 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gDkmQ-00087F-2M
for submit <at> debbugs.gnu.org; Sat, 20 Oct 2018 02:30:34 -0400
Received: from pop.dreamhost.com ([64.90.62.162]:57632
helo=pdx1-sub0-mail-a43.g.dreamhost.com)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <jidanni@HIDDEN>) id 1gDkmM-000875-7p
for 18328 <at> debbugs.gnu.org; Sat, 20 Oct 2018 02:30:30 -0400
Received: from pdx1-sub0-mail-a43.g.dreamhost.com (localhost [127.0.0.1])
by pdx1-sub0-mail-a43.g.dreamhost.com (Postfix) with ESMTP id 5CDAE80948;
Fri, 19 Oct 2018 23:30:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jidanni.org; h=from:to:cc
:subject:references:date:message-id:mime-version:content-type;
s=jidanni.org; bh=zJvQIblmhthlhGBqpJV3pM4Pii4=; b=mHKpn6UQIZcDU
k5XdURvz6gPIHcXs3t/l7Szk5s51kPZ+yj25jEkrnnwxhCc/yNXVdArlU1c36Jl9
9cAMCNJ2ey+HQlFhfu3MObqJ0SHjPihJCIEa0FQGy9DlUCrUXUWc7g/VM2gUNYtc
rB/mgO9AHvtWyTpDMR7B14yo6uixjo=
Received: from jidanni.org (220-140-13-84.dynamic-ip.hinet.net [220.140.13.84])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
(Authenticated sender: jidanni@HIDDEN)
by pdx1-sub0-mail-a43.g.dreamhost.com (Postfix) with ESMTPSA id AA17E80946;
Fri, 19 Oct 2018 23:30:28 -0700 (PDT)
X-DH-BACKEND: pdx1-sub0-mail-a43
From: =?UTF-8?Q?=E7=A9=8D=E4=B8=B9=E5=B0=BC?= Dan Jacobson <jidanni@HIDDEN>
References: <87ppfo36er.fsf@HIDDEN>
<c8968416-98b5-74ba-ffbe-cd49a23b173c@HIDDEN>
Date: Sat, 20 Oct 2018 14:30:25 +0800
Message-ID: <87sh11dta6.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrfeejgdduudduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhffffkgggtsehttdertddttdejnecuhfhrohhmpejnnjjnucffrghnucflrggtohgsshhonhcuoehjihgurghnnhhisehjihgurghnnhhirdhorhhgqeenucfkphepvddvtddrudegtddrudefrdekgeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepjhhiuggrnhhnihdrohhrghdpihhnvghtpedvvddtrddugedtrddufedrkeegpdhrvghtuhhrnhdqphgrthhhpeeprehuthhfqdekreeureehiehmpfehnfhiheehsgevkeerpecuffgrnhculfgrtghosghsohhnuceojhhiuggrnhhnihesjhhiuggrnhhnihdrohhrgheqpdhmrghilhhfrhhomhepjhhiuggrnhhnihesjhhiuggrnhhnihdrohhrghdpnhhrtghpthhtohepudekfedvkeesuggvsggsuhhgshdrghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedt
X-Spam-Score: 0.1 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.9 (/)
AG> I hope to get to this bug soon.
Good.
X-Loop: help-debbugs@HIDDEN
Subject: bug#18328: can't say date -d '8pm -0500' though other combos work
References: <87ppfo36er.fsf@HIDDEN>
In-Reply-To: <87ppfo36er.fsf@HIDDEN>
Resent-From: Jeffery Palm <palmje@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 29 Jul 2025 05:16:02 +0000
Resent-Message-ID: <handler.18328.B18328.175376610914371 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 18328
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: confirmed
To: 18328 <at> debbugs.gnu.org
Received: via spool by 18328-submit <at> debbugs.gnu.org id=B18328.175376610914371
(code B ref 18328); Tue, 29 Jul 2025 05:16:02 +0000
Received: (at 18328) by debbugs.gnu.org; 29 Jul 2025 05:15:09 +0000
Received: from localhost ([127.0.0.1]:59502 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ugcg7-0003jb-NC
for submit <at> debbugs.gnu.org; Tue, 29 Jul 2025 01:15:09 -0400
Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]:40901)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <palmje@HIDDEN>) id 1ugcUD-0002q5-5I
for 18328 <at> debbugs.gnu.org; Tue, 29 Jul 2025 01:02:49 -0400
Received: by mail-pf1-x430.google.com with SMTP id
d2e1a72fcca58-748e60725fcso627716b3a.3
for <18328 <at> debbugs.gnu.org>; Mon, 28 Jul 2025 22:02:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1753765363; x=1754370163; darn=debbugs.gnu.org;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=BSSK9TZkj5I0Qf/3FQIE4KjC8FsPxH3bdwuMYl0Dxuw=;
b=IE+1e7RPlQb/j0MXSPuQG85hPaWETO4BFtQ7OesesxkLMIwMdSQXsWH24yq4POfwaj
QX8HDZIVKOUTtA3xE0qVx0WWMDa6MXSPuDCVgA6NRDSGEUkplX3+ozQt/xtA5KNam9R2
R2tR4AFg8JzP2ac2I6LipJNcJfWmK+z+9FEje1QUx/7g5CTa42fShSOD3zn/eAj/vATW
3AIvNv5+81P0gOF2/I2YNThBv8N8rOcGJJ647rKelXnlj+1WvUbWc6iK0662GnTu6frn
TcbrKI6XMGcBO1aeQgdtGvaXuO5C21aUmWS5c/Tl6yBNGYhzpm3c61MEsA+Nv9kmKLRL
NQOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1753765363; x=1754370163;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=BSSK9TZkj5I0Qf/3FQIE4KjC8FsPxH3bdwuMYl0Dxuw=;
b=jeDM/w2tPobbyqnvRgXZSc++d/ETpKS8XX/qlmZTgpWLaw3xv0YxZtXhYExXLuF7I/
JeCT1NETxxAw2O5KXzrVSxlZNrDLGGPaUrFBb+NMlz4CZrF8wvKyEb5fZmYcDLPfiyTo
IoGCxATjMHFBNH1ICZNrQaWc3J0WzU9ylPCb0F5zstAzo5XugGC7Rvl+ANxZjQskMzKg
63J0mZlfmq0gT0Sq1uqnrXYWhgFRYDZ7P45el2w7GDH6P5QOrnTokF3yD5rH4otT+f5o
VCZ0+UegveoZ6LBlP6u7ew6vvD1zFijJ4prg1jILRH0+rz84AJH6OUrE3/ZfSgVqsO1H
zJCA==
X-Gm-Message-State: AOJu0YwFzmnBo0IsEaFeCwD185UO50rFiAo2ovJ4rwKrx2x/Bn0cZozW
BWd8czRORAh16/4tFF/aeY2+loti1Va/19HdBcr4siavC+qe8g8m9ODaiFHsnaw+y3mPCQEHPSr
ExqA8yvFLTWbhxclypItYzt9mTd9si5P4fmlQuDo=
X-Gm-Gg: ASbGncsQNLQDEwIyMiXZGFn6ZdQ1HT0mSEAlcuMqK6K/XzW+tEtSCCHHeaFtUKniEwH
KthrqwBFG2dMkRTxOQBYA5LO15zLicB4HjkMg0MlLAbpGh+ltq4AEdANsKLbeavWaw0FN2qBRCe
PCtcfvegfb+y73pbfdiJEQLe7r328KVU8AI1KVu2H50G6VmC+1s8z3KupJcGyltO3IxUreo2PHX
fqS6UA=
X-Google-Smtp-Source: AGHT+IETxprXuUOZ8KukxEejt86JhP9CipFj7jLg1iF4gNMQIUTMZ8ACIH9ExaJZjg3h2XU1HYYlIM0x36wagm/yIhA=
X-Received: by 2002:a05:6a21:6494:b0:231:242:2596 with SMTP id
adf61e73a8af0-23d7018390cmr9440322637.5.1753765362621; Mon, 28 Jul 2025
22:02:42 -0700 (PDT)
MIME-Version: 1.0
From: Jeffery Palm <palmje@HIDDEN>
Date: Mon, 28 Jul 2025 22:02:30 -0700
X-Gm-Features: Ac12FXwofEAAMGBNv9lBXbVm-NDLkNs1kFyfxm1krdChaHCkzibHitJmbB4RWJI
Message-ID: <CALPkt-PuUmx_Y=pp9W_7owS+qB7ULqo_vxgOpqt2jwA5W7SYmA@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000007560d4063b0a51ea"
X-Spam-Score: 0.0 (/)
X-Mailman-Approved-At: Tue, 29 Jul 2025 01:15:05 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--0000000000007560d4063b0a51ea
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I took a look at this bug, and believe I have a patch that will resolve it.
$ ../src/date --debug -d '2024-01-01 8:00:00PM -0500'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed time part: 08:00:00pm UTC-05
date: input timezone: parsed date/time string (-05)
date: using specified time as starting value: '20:00:00'
date: starting date/time: '(Y-M-D) 2024-01-01 20:00:00 TZ=3D-05'
date: '(Y-M-D) 2024-01-01 20:00:00 TZ=3D-05' =3D 1704157200 epoch-seconds
date: timezone: system default
date: final: 1704157200.000000000 (epoch-seconds)
date: final: (Y-M-D) 2024-01-02 01:00:00 (UTC)
date: final: (Y-M-D) 2024-01-01 17:00:00 (UTC-08)
date: output format: =E2=80=98%a %d %b %Y %T %Z=E2=80=99
Mon 01 Jan 2024 17:00:00 PST
And I was able to run the coreutils testsuite with no tests failing:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Testsuite summary for GNU coreutils 9.7.174-083f8
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
# TOTAL: 533
# PASS: 476
# SKIP: 57
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Are there any other tests/changes I should consider for this?
Below is the patch for the changes I made for this, including a new
testcase for AM/PM with timezone.
--- a/lib/parse-datetime.y
+++ b/lib/parse-datetime.y
@@ -592,7 +592,7 @@ debug_print_relative_time (char const *item,
parser_control const *pc)
%token tYEAR_UNIT tMONTH_UNIT tHOUR_UNIT tMINUTE_UNIT tSEC_UNIT
%token <intval> tDAY_UNIT tDAY_SHIFT
-%token <intval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN
+%token <intval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN tMERIDIAN_WITH_ZONE
%token <intval> tMONTH tORDINAL tZONE
%token <textintval> tSNUMBER tUNUMBER
@@ -698,6 +698,27 @@ time:
set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.tv_nsec);
pc->meridian =3D $6;
}
+ | tUNUMBER tMERIDIAN_WITH_ZONE tSNUMBER o_colon_minutes
+ {
+ set_hhmmss (pc, $1.value, 0, 0, 0);
+ pc->meridian =3D $2;
+ pc->zones_seen++;
+ if (! time_zone_hhmm (pc, $3, $4)) YYABORT;
+ }
+ | tUNUMBER ':' tUNUMBER tMERIDIAN_WITH_ZONE tSNUMBER o_colon_minutes
+ {
+ set_hhmmss (pc, $1.value, $3.value, 0, 0);
+ pc->meridian =3D $4;
+ pc->zones_seen++;
+ if (! time_zone_hhmm (pc, $5, $6)) YYABORT;
+ }
+ | tUNUMBER ':' tUNUMBER ':' unsigned_seconds tMERIDIAN_WITH_ZONE
tSNUMBER o_colon_minutes
+ {
+ set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.tv_nsec);
+ pc->meridian =3D $6;
+ pc->zones_seen++;
+ if (! time_zone_hhmm (pc, $7, $8)) YYABORT;
+ }
| iso_8601_time
;
@@ -1527,14 +1548,19 @@ yylex (union YYSTYPE *lvalp, parser_control *pc)
*p =3D '\0';
tp =3D lookup_word (pc, buff);
- if (! tp)
+ if (tp)
{
- if (debugging (pc))
- dbg_printf (_("error: unknown word '%s'\n"), buff);
- return '?';
+ lvalp->intval =3D tp->value;
+ if (tp->type =3D=3D tMERIDIAN)
+ {
+ char const *p =3D pc->input;
+ while (*p && c_isspace (*p))
+ p++;
+ if (*p =3D=3D '-' || *p =3D=3D '+')
+ return tMERIDIAN_WITH_ZONE;
+ }
+ return tp->type;
}
- lvalp->intval =3D tp->value;
- return tp->type;
}
if (c !=3D '(')
diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c
index 546b383c55..9766ed7a13 100644
--- a/tests/test-parse-datetime.c
+++ b/tests/test-parse-datetime.c
@@ -335,6 +335,15 @@ main (_GL_UNUSED int argc, char **argv)
ASSERT (result.tv_sec =3D=3D result2.tv_sec
&& result.tv_nsec =3D=3D result2.tv_nsec);
+ /* Check that timeone works with AM/PM */
+ p =3D "2024-01-01 8PM -08:00";
+ expected.tv_sec =3D 1704168000;
+ expected.tv_nsec =3D 0;
+ ASSERT (parse_datetime (&result, p, NULL));
+ LOG (p, expected, result);
+ ASSERT (expected.tv_sec =3D=3D result.tv_sec
+ && expected.tv_nsec =3D=3D result.tv_nsec);
+
/* TZ out of range should cause parse_datetime failure */
now.tv_sec =3D SOME_TIMEPOINT + 4711;
--0000000000007560d4063b0a51ea
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I took a look at this bug, and believe=C2=A0I have a =
patch that will resolve it.</div><div><br></div><div>$ ../src/date --debug =
-d '2024-01-01 8:00:00PM -0500'<br>date: parsed date part: (Y-M-D) =
2024-01-01<br>date: parsed time part: 08:00:00pm UTC-05<br>date: input time=
zone: parsed date/time string (-05)<br>date: using specified time as starti=
ng value: '20:00:00'<br>date: starting date/time: '(Y-M-D) 2024=
-01-01 20:00:00 TZ=3D-05'<br>date: '(Y-M-D) 2024-01-01 20:00:00 TZ=
=3D-05' =3D 1704157200 epoch-seconds<br>date: timezone: system default<=
br>date: final: 1704157200.000000000 (epoch-seconds)<br>date: final: (Y-M-D=
) 2024-01-02 01:00:00 (UTC)<br>date: final: (Y-M-D) 2024-01-01 17:00:00 (UT=
C-08)<br>date: output format: =E2=80=98%a %d %b %Y %T %Z=E2=80=99<br>Mon 01=
Jan 2024 17:00:00 PST</div><div><br></div><div><br></div><div>And I was ab=
le to run the coreutils testsuite with no tests failing:<br><br>=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Te=
stsuite summary for GNU coreutils 9.7.174-083f8<br>=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br># TOTAL: 533<br>#=
PASS: =C2=A0476<br># SKIP: =C2=A057<br># XFAIL: 0<br># FAIL: =C2=A00<br># =
XPASS: 0<br># ERROR: 0<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><br></div><div>Are there any other=
tests/changes I should consider for this?</div><div><br></div><div><br></d=
iv><div>Below is the patch for the changes I made for this, including a new=
testcase=C2=A0for AM/PM with timezone.=C2=A0</div><div><br></div><div><br>=
</div><div>--- a/lib/parse-datetime.y<br>+++ b/lib/parse-datetime.y<br>@@ -=
592,7 +592,7 @@ debug_print_relative_time (char const *item, parser_control=
const *pc)<br>=C2=A0%token tYEAR_UNIT tMONTH_UNIT tHOUR_UNIT tMINUTE_UNIT =
tSEC_UNIT<br>=C2=A0%token <intval> tDAY_UNIT tDAY_SHIFT<br>=C2=A0<br>=
-%token <intval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN<br>+%token <i=
ntval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN tMERIDIAN_WITH_ZONE<br>=C2=A0=
%token <intval> tMONTH tORDINAL tZONE<br>=C2=A0<br>=C2=A0%token <t=
extintval> tSNUMBER tUNUMBER<br>@@ -698,6 +698,27 @@ time:<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.t=
v_nsec);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc->meridian =3D $6;<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>+ =C2=A0| tUNUMBER tMERIDIAN_WITH_ZONE tSNU=
MBER o_colon_minutes<br>+ =C2=A0 =C2=A0 =C2=A0{<br>+ =C2=A0 =C2=A0 =C2=A0 =
=C2=A0set_hhmmss (pc, $1.value, 0, 0, 0);<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0p=
c->meridian =3D $2;<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0pc->zones_seen++;=
<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0if (! time_zone_hhmm (pc, $3, $4)) YYABORT=
;<br>+ =C2=A0 =C2=A0 =C2=A0}<br>+ =C2=A0| tUNUMBER ':' tUNUMBER tME=
RIDIAN_WITH_ZONE tSNUMBER o_colon_minutes<br>+ =C2=A0 =C2=A0 =C2=A0{<br>+ =
=C2=A0 =C2=A0 =C2=A0 =C2=A0set_hhmmss (pc, $1.value, $3.value, 0, 0);<br>+ =
=C2=A0 =C2=A0 =C2=A0 =C2=A0pc->meridian =3D $4;<br>+ =C2=A0 =C2=A0 =C2=
=A0 =C2=A0pc->zones_seen++;<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0if (! time_z=
one_hhmm (pc, $5, $6)) YYABORT;<br>+ =C2=A0 =C2=A0 =C2=A0}<br>+ =C2=A0| tUN=
UMBER ':' tUNUMBER ':' unsigned_seconds tMERIDIAN_WITH_ZONE=
tSNUMBER o_colon_minutes<br>+ =C2=A0 =C2=A0 =C2=A0{<br>+ =C2=A0 =C2=A0 =C2=
=A0 =C2=A0set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.tv_nsec);<br>+ =
=C2=A0 =C2=A0 =C2=A0 =C2=A0pc->meridian =3D $6;<br>+ =C2=A0 =C2=A0 =C2=
=A0 =C2=A0pc->zones_seen++;<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0if (! time_z=
one_hhmm (pc, $7, $8)) YYABORT;<br>+ =C2=A0 =C2=A0 =C2=A0}<br>=C2=A0 =C2=A0=
| iso_8601_time<br>=C2=A0 =C2=A0;<br>=C2=A0<br>@@ -1527,14 +1548,19 @@ yyle=
x (union YYSTYPE *lvalp, parser_control *pc)<br>=C2=A0<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0*p =3D '\0';<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0tp =3D lookup_word (pc, buff);<br>- =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0if (! tp)<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (tp)<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>- =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0if (debugging (pc))<br>- =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dbg_printf (_("error: unknown word &=
#39;%s'\n"), buff);<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0return '?';<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0lvalp->intval =3D tp->value;<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0if (tp->type =3D=3D tMERIDIAN)<br>+ =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0char const *p =3D pc->input;<br>+ =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0while (*p &&=
amp; c_isspace (*p))<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0p++;<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0if (*p =3D=3D '-' || *p =3D=3D '+')<br>+ =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return=
tMERIDIAN_WITH_ZONE;<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0}<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return tp->=
;type;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>- =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0lvalp->intval =3D tp->value;<br>- =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0return tp->type;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0}<br>=C2=A0<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0if (c !=3D '(')<br>=
diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c<br>i=
ndex 546b383c55..9766ed7a13 100644<br>--- a/tests/test-parse-datetime.c<br>=
+++ b/tests/test-parse-datetime.c<br>@@ -335,6 +335,15 @@ main (_GL_UNUSED =
int argc, char **argv)<br>=C2=A0 =C2=A0ASSERT (result.tv_sec =3D=3D result2=
.tv_sec<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&& result.tv_ns=
ec =3D=3D result2.tv_nsec);<br>=C2=A0<br>+ =C2=A0/* Check that timeone work=
s with AM/PM */<br>+ =C2=A0p =3D "2024-01-01 8PM -08:00";<br>+ =
=C2=A0expected.tv_sec =3D 1704168000;<br>+ =C2=A0expected.tv_nsec =3D 0;<br=
>+ =C2=A0ASSERT (parse_datetime (&result, p, NULL));<br>+ =C2=A0LOG (p,=
expected, result);<br>+ =C2=A0ASSERT (expected.tv_sec =3D=3D result.tv_sec=
<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&& expected.tv_nsec =3D=3D =
result.tv_nsec);<br>+<br>=C2=A0<br>=C2=A0 =C2=A0/* TZ out of range should c=
ause parse_datetime failure */<br>=C2=A0 =C2=A0now.tv_sec =3D SOME_TIMEPOIN=
T + 4711;</div></div>
--0000000000007560d4063b0a51ea--
X-Loop: help-debbugs@HIDDEN
Subject: bug#18328: can't say date -d '8pm -0500' though other combos work
Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 29 Jul 2025 11:23:02 +0000
Resent-Message-ID: <handler.18328.B18328.175378816421994 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 18328
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: confirmed
To: Jeffery Palm <palmje@HIDDEN>, 18328 <at> debbugs.gnu.org
Cc: Geoff Kuenning <geoff@HIDDEN>
Received: via spool by 18328-submit <at> debbugs.gnu.org id=B18328.175378816421994
(code B ref 18328); Tue, 29 Jul 2025 11:23:02 +0000
Received: (at 18328) by debbugs.gnu.org; 29 Jul 2025 11:22:44 +0000
Received: from localhost ([127.0.0.1]:60895 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ugiPr-0005if-LH
for submit <at> debbugs.gnu.org; Tue, 29 Jul 2025 07:22:44 -0400
Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:51440)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <pixelbeat@HIDDEN>)
id 1ugiPo-0005iA-OZ
for 18328 <at> debbugs.gnu.org; Tue, 29 Jul 2025 07:22:42 -0400
Received: by mail-wm1-x335.google.com with SMTP id
5b1f17b1804b1-4538bc52a8dso40388635e9.2
for <18328 <at> debbugs.gnu.org>; Tue, 29 Jul 2025 04:22:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1753788154; x=1754392954; darn=debbugs.gnu.org;
h=content-transfer-encoding:in-reply-to:cc:from:content-language
:references:to:subject:user-agent:mime-version:date:message-id
:sender:from:to:cc:subject:date:message-id:reply-to;
bh=My4k/0ua/s0rvkS3F6UuacesDLlE7JtsDY5q93LGMXo=;
b=mWrNSXtWaog5Ztpd83nPMo4+SkOHXNBCaI//AtvcK6pTyq3UmLHv4Ac8cWov9QhzcP
fFK5iSEhHrfQofKYf04MzV6WtvDB/N8+mT9e0WZuA1crOUTKtp4o5Tz6vZTE06e0PIbU
YuHhoTn70OgeFWxrxmJ45YvmJjzcaJUwGQrHt/9DNdrbLaJrpZCaj6L8r7Vc6iidT8+4
WxrXu1ZHKlOOvfYKe+mse+0SHywDK4JGDIF7Rrv9lCE/1wCQO/E4tlbH/lM6OEfc74gH
GixNa1rEl3b4LEgIC3BrSExDs7Bzp0NJAuIQvLcZ7Qf0UxgnZQhVJx//DDQnIxLYO/dL
QcKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1753788154; x=1754392954;
h=content-transfer-encoding:in-reply-to:cc:from:content-language
:references:to:subject:user-agent:mime-version:date:message-id
:sender:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=My4k/0ua/s0rvkS3F6UuacesDLlE7JtsDY5q93LGMXo=;
b=k0L66W8Bj80yaDfgL8EJ+D5C8yY3mKj/FmnQLXfkYTxJ8fqWzUUref2gW48pPtswSY
QmfCTeCR51cnBpc0DPRRdePW7wgIMzaX15Y63Le7MmSuO23H01xvDgulrtG1JVg/wv7R
QaeuYLseZzJwClzk7G553653QfY1MgbofXRHgxzzIU5K6Q2NDtyP5oH/YWeWa4esH6jv
UFjw0wKxIFQUfuR0Plwyle2A2yZG6wMbXAktZO4A/UgeRzlavgiUsVk3NoAYybAogMPy
sClUMuff40qkGmyf1/y6ZXRYsOU6UR+700k1ymwUBIF/GBjuEPfTbMbEm149u92Q1IB3
y21w==
X-Forwarded-Encrypted: i=1;
AJvYcCUQLlAXnonSx2Unm0UVO2PMe0fROhrZKpfVNy10GTmj8+A90Hu9ZoK0He0OZ3t9tkPZaEDj9g==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzkXtzf4AfcEwcOxqZRxrE3gzK/LtB/YYJjwJyNPv+v2ou3qS17
RDIWKrvXtjoxL9boaX1WPDxWy4pr9AttzPZeWJpq8Dyw8puTXY/sUMmk
X-Gm-Gg: ASbGncucS1nIbAH79MIDMtfxzsvFVVOtX/u7hoVHvDE2206geekVuC2P/O2cwycq/st
QcJX4aunO+fgcn8mUX8f8sMT+nM1bAIcUEs4Duz9sIov1VCMToYnJLqtURuhSVgwMaecwus0Ren
ZPY7g6sfQHfY+Y1ZzA+7u8XEK6Ds7FokvCK3OBN1BwV0GElvXSyNmTla2nP2ZIKoq2Uigfc57pY
mt3fYv9ruPhd3Tts6e3ZTstTmRZEkmIReBqHplC1gsq5jGWzQ2sGhIGJnICBLkwRXUhXjGD/2WM
X+oIG9hF3ZsKobW+WaKhcv3wyQHlr2E+b0YWrPgCaBc1JYZRwvVWIYVy6egs9ZwuCBzWR+c770k
QLwPtBL+eJywKP7nuPbPXW/H9tiBtz0E/C8G4NE6Rm6Nzb+5XS0CSY0x74NFXbxtc9Y9/PXzcym
jeiBmGYWkbtxF6
X-Google-Smtp-Source: AGHT+IHB7ZT/rgpJvo5E+hVMnSrYaPMMJFeDEVNKli1RzXu/b60oTWQb8DYjHwC5XtjF2ND4Xtv1Pg==
X-Received: by 2002:a05:600c:518d:b0:456:2bac:8f8 with SMTP id
5b1f17b1804b1-45876449eb8mr126156935e9.16.1753788153849;
Tue, 29 Jul 2025 04:22:33 -0700 (PDT)
Received: from [192.168.1.31]
(86-44-211-146-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.44.211.146])
by smtp.googlemail.com with ESMTPSA id
5b1f17b1804b1-4588e5c58e9sm20400625e9.14.2025.07.29.04.22.32
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Tue, 29 Jul 2025 04:22:33 -0700 (PDT)
Message-ID: <3c15c4fd-de25-4333-aeb6-af70dd02e29a@HIDDEN>
Date: Tue, 29 Jul 2025 12:22:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
References: <87ppfo36er.fsf@HIDDEN>
<CALPkt-PuUmx_Y=pp9W_7owS+qB7ULqo_vxgOpqt2jwA5W7SYmA@HIDDEN>
Content-Language: en-US
From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
In-Reply-To: <CALPkt-PuUmx_Y=pp9W_7owS+qB7ULqo_vxgOpqt2jwA5W7SYmA@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 29/07/2025 06:02, Jeffery Palm wrote:
> I took a look at this bug, and believe I have a patch that will resolve it.
>
> $ ../src/date --debug -d '2024-01-01 8:00:00PM -0500'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed time part: 08:00:00pm UTC-05
> date: input timezone: parsed date/time string (-05)
> date: using specified time as starting value: '20:00:00'
> date: starting date/time: '(Y-M-D) 2024-01-01 20:00:00 TZ=-05'
> date: '(Y-M-D) 2024-01-01 20:00:00 TZ=-05' = 1704157200 epoch-seconds
> date: timezone: system default
> date: final: 1704157200.000000000 (epoch-seconds)
> date: final: (Y-M-D) 2024-01-02 01:00:00 (UTC)
> date: final: (Y-M-D) 2024-01-01 17:00:00 (UTC-08)
> date: output format: ‘%a %d %b %Y %T %Z’
> Mon 01 Jan 2024 17:00:00 PST
>
>
> And I was able to run the coreutils testsuite with no tests failing:
>
> ============================================================================
> Testsuite summary for GNU coreutils 9.7.174-083f8
> ============================================================================
> # TOTAL: 533
> # PASS: 476
> # SKIP: 57
> # XFAIL: 0
> # FAIL: 0
> # XPASS: 0
> # ERROR: 0
> ============================================================================
>
> Are there any other tests/changes I should consider for this?
>
>
> Below is the patch for the changes I made for this, including a new
> testcase for AM/PM with timezone.
>
>
> --- a/lib/parse-datetime.y
> +++ b/lib/parse-datetime.y
> @@ -592,7 +592,7 @@ debug_print_relative_time (char const *item,
> parser_control const *pc)
> %token tYEAR_UNIT tMONTH_UNIT tHOUR_UNIT tMINUTE_UNIT tSEC_UNIT
> %token <intval> tDAY_UNIT tDAY_SHIFT
>
> -%token <intval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN
> +%token <intval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN tMERIDIAN_WITH_ZONE
> %token <intval> tMONTH tORDINAL tZONE
>
> %token <textintval> tSNUMBER tUNUMBER
> @@ -698,6 +698,27 @@ time:
> set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.tv_nsec);
> pc->meridian = $6;
> }
> + | tUNUMBER tMERIDIAN_WITH_ZONE tSNUMBER o_colon_minutes
> + {
> + set_hhmmss (pc, $1.value, 0, 0, 0);
> + pc->meridian = $2;
> + pc->zones_seen++;
> + if (! time_zone_hhmm (pc, $3, $4)) YYABORT;
> + }
> + | tUNUMBER ':' tUNUMBER tMERIDIAN_WITH_ZONE tSNUMBER o_colon_minutes
> + {
> + set_hhmmss (pc, $1.value, $3.value, 0, 0);
> + pc->meridian = $4;
> + pc->zones_seen++;
> + if (! time_zone_hhmm (pc, $5, $6)) YYABORT;
> + }
> + | tUNUMBER ':' tUNUMBER ':' unsigned_seconds tMERIDIAN_WITH_ZONE
> tSNUMBER o_colon_minutes
> + {
> + set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.tv_nsec);
> + pc->meridian = $6;
> + pc->zones_seen++;
> + if (! time_zone_hhmm (pc, $7, $8)) YYABORT;
> + }
> | iso_8601_time
> ;
>
> @@ -1527,14 +1548,19 @@ yylex (union YYSTYPE *lvalp, parser_control *pc)
>
> *p = '\0';
> tp = lookup_word (pc, buff);
> - if (! tp)
> + if (tp)
> {
> - if (debugging (pc))
> - dbg_printf (_("error: unknown word '%s'\n"), buff);
> - return '?';
> + lvalp->intval = tp->value;
> + if (tp->type == tMERIDIAN)
> + {
> + char const *p = pc->input;
Better to use a non shadowing name here ^
> + while (*p && c_isspace (*p))
> + p++;
> + if (*p == '-' || *p == '+')
> + return tMERIDIAN_WITH_ZONE;
> + }
> + return tp->type;
> }
> - lvalp->intval = tp->value;
> - return tp->type;
> }
>
> if (c != '(')
> diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c
> index 546b383c55..9766ed7a13 100644
> --- a/tests/test-parse-datetime.c
> +++ b/tests/test-parse-datetime.c
> @@ -335,6 +335,15 @@ main (_GL_UNUSED int argc, char **argv)
> ASSERT (result.tv_sec == result2.tv_sec
> && result.tv_nsec == result2.tv_nsec);
>
> + /* Check that timeone works with AM/PM */
> + p = "2024-01-01 8PM -08:00";
> + expected.tv_sec = 1704168000;
> + expected.tv_nsec = 0;
> + ASSERT (parse_datetime (&result, p, NULL));
> + LOG (p, expected, result);
> + ASSERT (expected.tv_sec == result.tv_sec
> + && expected.tv_nsec == result.tv_nsec);
> +
>
> /* TZ out of range should cause parse_datetime failure */
> now.tv_sec = SOME_TIMEPOINT + 4711;
Thanks for looking at this.
This changes relative handling unfortunately:
$ src/date --debug -d '2024-01-01 8:00:00PM -5 days'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed time part: 08:00:00pm UTC-05
date: parsed relative part: +1 day(s)
...
Wed 03 Jan 2024 01:00:00 GMT
$ date --debug -d '2024-01-01 8:00:00PM -5 days'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed time part: 08:00:00pm
date: parsed relative part: -5 day(s)
...
Wed 27 Dec 2023 20:00:00 GMT
Now there is an existing ambiguity here,
where the AM/PM induces the relative interpretation:
$ date --debug -d '2024-01-01 8:00:00PM -5 days'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed time part: 08:00:00pm
date: parsed relative part: -5 day(s)
$ date --debug -d '2024-01-01 8:00:00 -5 days'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed time part: 08:00:00 UTC-05
date: parsed relative part: +1 day(s)
BTW https://bugs.gnu.org/79078 was a recent bug report
along the same lines of the relative part being unexpectedly
considered as a timezone offset
Now I agree we're already inconsistent in this regard, but I'm sure
folks are relying on the AM/PM inducing a relative interpretation.
If we were trying to make all this more consistent, IMHO
we should change things so that we always interpret +|-<int> <days|minutes|...>
as a relative adjustment, whereas your change does the opposite for the AM/PM case.
cheers,
Padraig
X-Loop: help-debbugs@HIDDEN
Subject: bug#18328: can't say date -d '8pm -0500' though other combos work
Resent-From: Jeffery Palm <palmje@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 25 Nov 2025 20:22:18 +0000
Resent-Message-ID: <handler.18328.B18328.17641021334015 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 18328
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: confirmed
To: P@HIDDEN
Cc: 18328 <at> debbugs.gnu.org, Geoff Kuenning <geoff@HIDDEN>
Received: via spool by 18328-submit <at> debbugs.gnu.org id=B18328.17641021334015
(code B ref 18328); Tue, 25 Nov 2025 20:22:18 +0000
Received: (at 18328) by debbugs.gnu.org; 25 Nov 2025 20:22:13 +0000
Received: from localhost ([127.0.0.1]:41854 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vNzYB-00011z-8b
for submit <at> debbugs.gnu.org; Tue, 25 Nov 2025 15:22:13 -0500
Received: from mail-pl1-x634.google.com ([2607:f8b0:4864:20::634]:39638)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <palmje@HIDDEN>) id 1vN2tV-0006YC-3Y
for 18328 <at> debbugs.gnu.org; Sun, 23 Nov 2025 00:44:18 -0500
Received: by mail-pl1-x634.google.com with SMTP id
d9443c01a7336-297cf964774so5751905ad.2
for <18328 <at> debbugs.gnu.org>; Sat, 22 Nov 2025 21:44:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1763876647; x=1764481447; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=uEsAFVYsKdBbfnCSlKJMNQbeJgelOxEelf+czISGd0I=;
b=K8Ig1l46IAxZpDQFwFldq3i6C17CvUK8AETdaJNFuPZjZlpQ052OsD9Jl/7lDb3i4i
i/Qt5nL6WjYuKqcet2NyJ3DyalCq+b+P14NMI9DKc7Q5yaBr+i3OM1xX84lijbgFu2vG
t+MI6EMe+raK7gN0Ab80jBbjIcfshzawimdrXQotNrogs/y+VwNvLbw2gj5/FmS3gWCF
7qY488ipqVmHOLIr5ROAiCSln0uFopGFQwy4PjXXainc0Spo168QW1iUpliVfdf2gtdU
7xmEC7/3hIXZ1K7PIy4Qks5s7j4Jhaw8+C2lGm5JsdEJG36k43eNzRZrlK97NiH7Vwt2
zRdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1763876647; x=1764481447;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=uEsAFVYsKdBbfnCSlKJMNQbeJgelOxEelf+czISGd0I=;
b=dl+EkLeAGgR6luynUvfJd1He42mQg9bTLwsP3mJHjZohVlE0SWcPjQtBC7ZDQ9wYii
93TKeWsYVuViyWKWbnn0JBryKMDQICN2dsCj8wbUgxRoQM2syHk7Y3QJsicDvf6LuzFu
+wh1gkN3lVCqPI3B8FtRe5xGJu0OG85C0wlLQNWa9GnBWv+6Wd5RkRbLMaZnWUNDqbca
KML/Hazf6zNHEaN7JL4BvUlsPcl5NuxMOHVQxwBWPdgcSiJFx19tkem/n9ez5Cz+kUXt
oqDn7ORbNu/KswHdkJmpSFdYBoaRaPBZvviE7p5e5wsEOHq+CYcIAAkwOziQziPW2oZK
PRdA==
X-Gm-Message-State: AOJu0YyOquLcJwT5aEKfzgT85r8Boatt1DzJEIoqxf2+ml+XHuNLMzbA
RjzRV84v9JvbbRlz5XwgW0+LvXEZBz8kPYtZcd46W/fv34PCuVLYdmSGoGoGmNcr+PvcJvnqi4R
+0d9RVkw9QwamGWHBd957hhrglvkEGLM=
X-Gm-Gg: ASbGncuE2/TyqYe2shRwZYCfJAooAxrg9waZOkvjOJeTaej/cp6apT3xrNKra3+CYIr
UwsMF4EqhvYhxLUzKDHArnmrh5Hc9zBlkp+5ZX08XO+cQfKB6Cgpfk1g7YzAQnkCPbf6WQqMMIB
jHalgsUWwVOkFvAYRa67Wg5tBNdYs3G+g8XOgEZt/q/aG7UB53EUsEynzC9SqkosZN4flcFh03C
MK9igHOBpLGPqMU5bkaB3fLWidypfTb+FAmEOsx9pG2Di1rYOnQDisO6gM7ShDHwoxj1dU=
X-Google-Smtp-Source: AGHT+IEDpFPb+XJDme+/FiMO8bSR4nibDkqs9LD1KksTo/cQVq0y4YMA3qSmGDJups8dc0sJRBeUlZzZhKu1ggiDGn4=
X-Received: by 2002:a05:7022:6299:b0:11b:1c6d:98ed with SMTP id
a92af1059eb24-11c9f31a210mr3710078c88.2.1763876646739; Sat, 22 Nov 2025
21:44:06 -0800 (PST)
MIME-Version: 1.0
References: <87ppfo36er.fsf@HIDDEN>
<CALPkt-PuUmx_Y=pp9W_7owS+qB7ULqo_vxgOpqt2jwA5W7SYmA@HIDDEN>
<3c15c4fd-de25-4333-aeb6-af70dd02e29a@HIDDEN>
In-Reply-To: <3c15c4fd-de25-4333-aeb6-af70dd02e29a@HIDDEN>
From: Jeffery Palm <palmje@HIDDEN>
Date: Sat, 22 Nov 2025 21:43:54 -0800
X-Gm-Features: AWmQ_bmalKLPirWh1uTwJXleOdPO_uPXlh6iHpJvrZsXtz-MpoaEfsz_yuqZvHk
Message-ID: <CALPkt-O0Yfd+3N78z9V3ZmXUR4s4x0OBtJv8NSZ0KLu4aN=AGg@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000f4e2b906443c8822"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--000000000000f4e2b906443c8822
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Padraig,
Thanks for the feedback.
I was able to get back to this and have a look at getting this
inconsistency resolved, and I was able to find a change that seems to
resolve this inconsistency.
It is still correctly parsing the timezone with AM/PM:
$ ./src/date --debug -d '2024-01-01 8:00:00PM -0500'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed time part: 08:00:00pm UTC-05
date: input timezone: parsed date/time string (-05)
date: using specified time as starting value: '20:00:00'
date: starting date/time: '(Y-M-D) 2024-01-01 20:00:00 TZ=3D-05'
date: '(Y-M-D) 2024-01-01 20:00:00 TZ=3D-05' =3D 1704157200 epoch-seconds
date: timezone: system default
date: final: 1704157200.000000000 (epoch-seconds)
date: final: (Y-M-D) 2024-01-02 01:00:00 (UTC)
date: final: (Y-M-D) 2024-01-01 17:00:00 (UTC-08)
date: output format: =E2=80=98%a %d %b %Y %T %Z=E2=80=99
Mon 01 Jan 2024 17:00:00 PST
And will now correctly prioritize time offset with a ime unit is specified,
both with AM/PM and without:
$ ./src/date --debug -d '2024-01-01 8:00:00 -5 days'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed relative part: -5 day(s)
date: parsed time part: 08:00:00
date: input timezone: system default
date: using specified time as starting value: '08:00:00'
date: starting date/time: '(Y-M-D) 2024-01-01 08:00:00'
date: warning: when adding relative days, it is recommended to specify noon
date: after date adjustment (+0 years, +0 months, -5 days),
date: new date/time =3D '(Y-M-D) 2023-12-27 08:00:00'
date: '(Y-M-D) 2023-12-27 08:00:00' =3D 1703692800 epoch-seconds
date: timezone: system default
date: final: 1703692800.000000000 (epoch-seconds)
date: final: (Y-M-D) 2023-12-27 16:00:00 (UTC)
date: final: (Y-M-D) 2023-12-27 08:00:00 (UTC-08)
date: output format: =E2=80=98%a %d %b %Y %T %Z=E2=80=99
Wed 27 Dec 2023 08:00:00 PST
$ ./src/date --debug -d '2024-01-01 8:00:00AM -5 days'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed relative part: -5 day(s)
date: parsed time part: 08:00:00
date: input timezone: system default
date: using specified time as starting value: '08:00:00'
date: starting date/time: '(Y-M-D) 2024-01-01 08:00:00'
date: warning: when adding relative days, it is recommended to specify noon
date: after date adjustment (+0 years, +0 months, -5 days),
date: new date/time =3D '(Y-M-D) 2023-12-27 08:00:00'
date: '(Y-M-D) 2023-12-27 08:00:00' =3D 1703692800 epoch-seconds
date: timezone: system default
date: final: 1703692800.000000000 (epoch-seconds)
date: final: (Y-M-D) 2023-12-27 16:00:00 (UTC)
date: final: (Y-M-D) 2023-12-27 08:00:00 (UTC-08)
date: output format: =E2=80=98%a %d %b %Y %T %Z=E2=80=99
Wed 27 Dec 2023 08:00:00 PST
And the coreutils complete testsuite is passing:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Testsuite summary for GNU coreutils 9.9.31-1d58e
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
# TOTAL: 575
# PASS: 518
# SKIP: 57
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
Below is the full patch:
diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
index 6c52cd2c4c..71f8b9ae0e 100644
--- a/lib/parse-datetime.y
+++ b/lib/parse-datetime.y
@@ -573,8 +573,8 @@ debug_print_relative_time (char const *item,
parser_control const *pc)
%parse-param { parser_control *pc }
%lex-param { parser_control *pc }
-/* This grammar has 31 shift/reduce conflicts. */
-%expect 31
+/* This grammar has 40 shift/reduce conflicts. */
+%expect 40
%union
{
@@ -681,17 +681,17 @@ iso_8601_datetime:
;
time:
- tUNUMBER tMERIDIAN
+ tUNUMBER tMERIDIAN o_zone_offset
{
set_hhmmss (pc, $1.value, 0, 0, 0);
pc->meridian =3D $2;
}
- | tUNUMBER ':' tUNUMBER tMERIDIAN
+ | tUNUMBER ':' tUNUMBER tMERIDIAN o_zone_offset
{
set_hhmmss (pc, $1.value, $3.value, 0, 0);
pc->meridian =3D $4;
}
- | tUNUMBER ':' tUNUMBER ':' unsigned_seconds tMERIDIAN
+ | tUNUMBER ':' tUNUMBER ':' unsigned_seconds tMERIDIAN o_zone_offset
{
set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.tv_nsec);
pc->meridian =3D $6;
@@ -720,6 +720,11 @@ iso_8601_time:
o_zone_offset:
/* empty */
| zone_offset
+ | relunit_snumber
+ {
+ if (! apply_relative_time (pc, $1, 1)) YYABORT;
+ debug_print_relative_time (_("relative"), pc);
+ }
;
zone_offset:
diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c
index 23c8598a6f..8bfb7210d6 100644
--- a/tests/test-parse-datetime.c
+++ b/tests/test-parse-datetime.c
@@ -334,6 +334,31 @@ main (_GL_UNUSED int argc, char **argv)
ASSERT (result.tv_sec =3D=3D result2.tv_sec
&& result.tv_nsec =3D=3D result2.tv_nsec);
+ /* Check that timeone works with AM/PM */
+ p =3D "2024-01-01 8PM -08:00";
+ expected.tv_sec =3D 1704168000;
+ expected.tv_nsec =3D 0;
+ ASSERT (parse_datetime (&result, p, NULL));
+ LOG (p, expected, result);
+ ASSERT (expected.tv_sec =3D=3D result.tv_sec
+ && expected.tv_nsec =3D=3D result.tv_nsec);
+
+ /* Check that date offset is preferred to timezone */
+ p =3D "2024-01-01 8PM -5 days";
+ expected.tv_sec =3D 1703725200;
+ expected.tv_nsec =3D 0;
+ ASSERT (parse_datetime (&result, p, NULL));
+ LOG (p, expected, result);
+ ASSERT (expected.tv_sec =3D=3D result.tv_sec
+ && expected.tv_nsec =3D=3D result.tv_nsec);
+
+ p =3D "2024-01-01 20:00 -5 days";
+ expected.tv_sec =3D 1703725200;
+ expected.tv_nsec =3D 0;
+ ASSERT (parse_datetime (&result, p, NULL));
+ LOG (p, expected, result);
+ ASSERT (expected.tv_sec =3D=3D result.tv_sec
+ && expected.tv_nsec =3D=3D result.tv_nsec);
/* TZ out of range should cause parse_datetime failure */
now.tv_sec =3D SOME_TIMEPOINT + 4711;
Regards.
Jeff
On Tue, 29 Jul 2025 at 04:22, P=C3=A1draig Brady <P@HIDDEN> wrote:
> On 29/07/2025 06:02, Jeffery Palm wrote:
> > I took a look at this bug, and believe I have a patch that will resolve
> it.
> >
> > $ ../src/date --debug -d '2024-01-01 8:00:00PM -0500'
> > date: parsed date part: (Y-M-D) 2024-01-01
> > date: parsed time part: 08:00:00pm UTC-05
> > date: input timezone: parsed date/time string (-05)
> > date: using specified time as starting value: '20:00:00'
> > date: starting date/time: '(Y-M-D) 2024-01-01 20:00:00 TZ=3D-05'
> > date: '(Y-M-D) 2024-01-01 20:00:00 TZ=3D-05' =3D 1704157200 epoch-secon=
ds
> > date: timezone: system default
> > date: final: 1704157200.000000000 (epoch-seconds)
> > date: final: (Y-M-D) 2024-01-02 01:00:00 (UTC)
> > date: final: (Y-M-D) 2024-01-01 17:00:00 (UTC-08)
> > date: output format: =E2=80=98%a %d %b %Y %T %Z=E2=80=99
> > Mon 01 Jan 2024 17:00:00 PST
> >
> >
> > And I was able to run the coreutils testsuite with no tests failing:
> >
> >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > Testsuite summary for GNU coreutils 9.7.174-083f8
> >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> > # TOTAL: 533
> > # PASS: 476
> > # SKIP: 57
> > # XFAIL: 0
> > # FAIL: 0
> > # XPASS: 0
> > # ERROR: 0
> >
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> >
> > Are there any other tests/changes I should consider for this?
> >
> >
> > Below is the patch for the changes I made for this, including a new
> > testcase for AM/PM with timezone.
> >
> >
> > --- a/lib/parse-datetime.y
> > +++ b/lib/parse-datetime.y
> > @@ -592,7 +592,7 @@ debug_print_relative_time (char const *item,
> > parser_control const *pc)
> > %token tYEAR_UNIT tMONTH_UNIT tHOUR_UNIT tMINUTE_UNIT tSEC_UNIT
> > %token <intval> tDAY_UNIT tDAY_SHIFT
> >
> > -%token <intval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN
> > +%token <intval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN tMERIDIAN_WITH_ZON=
E
> > %token <intval> tMONTH tORDINAL tZONE
> >
> > %token <textintval> tSNUMBER tUNUMBER
> > @@ -698,6 +698,27 @@ time:
> > set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.tv_nsec);
> > pc->meridian =3D $6;
> > }
> > + | tUNUMBER tMERIDIAN_WITH_ZONE tSNUMBER o_colon_minutes
> > + {
> > + set_hhmmss (pc, $1.value, 0, 0, 0);
> > + pc->meridian =3D $2;
> > + pc->zones_seen++;
> > + if (! time_zone_hhmm (pc, $3, $4)) YYABORT;
> > + }
> > + | tUNUMBER ':' tUNUMBER tMERIDIAN_WITH_ZONE tSNUMBER o_colon_minutes
> > + {
> > + set_hhmmss (pc, $1.value, $3.value, 0, 0);
> > + pc->meridian =3D $4;
> > + pc->zones_seen++;
> > + if (! time_zone_hhmm (pc, $5, $6)) YYABORT;
> > + }
> > + | tUNUMBER ':' tUNUMBER ':' unsigned_seconds tMERIDIAN_WITH_ZONE
> > tSNUMBER o_colon_minutes
> > + {
> > + set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.tv_nsec);
> > + pc->meridian =3D $6;
> > + pc->zones_seen++;
> > + if (! time_zone_hhmm (pc, $7, $8)) YYABORT;
> > + }
> > | iso_8601_time
> > ;
> >
> > @@ -1527,14 +1548,19 @@ yylex (union YYSTYPE *lvalp, parser_control *pc=
)
> >
> > *p =3D '\0';
> > tp =3D lookup_word (pc, buff);
> > - if (! tp)
> > + if (tp)
> > {
> > - if (debugging (pc))
> > - dbg_printf (_("error: unknown word '%s'\n"), buff);
> > - return '?';
> > + lvalp->intval =3D tp->value;
> > + if (tp->type =3D=3D tMERIDIAN)
> > + {
> > + char const *p =3D pc->input;
>
> Better to use a non shadowing name here ^
>
> > + while (*p && c_isspace (*p))
> > + p++;
> > + if (*p =3D=3D '-' || *p =3D=3D '+')
> > + return tMERIDIAN_WITH_ZONE;
> > + }
> > + return tp->type;
> > }
> > - lvalp->intval =3D tp->value;
> > - return tp->type;
> > }
> >
> > if (c !=3D '(')
> > diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c
> > index 546b383c55..9766ed7a13 100644
> > --- a/tests/test-parse-datetime.c
> > +++ b/tests/test-parse-datetime.c
> > @@ -335,6 +335,15 @@ main (_GL_UNUSED int argc, char **argv)
> > ASSERT (result.tv_sec =3D=3D result2.tv_sec
> > && result.tv_nsec =3D=3D result2.tv_nsec);
> >
> > + /* Check that timeone works with AM/PM */
> > + p =3D "2024-01-01 8PM -08:00";
> > + expected.tv_sec =3D 1704168000;
> > + expected.tv_nsec =3D 0;
> > + ASSERT (parse_datetime (&result, p, NULL));
> > + LOG (p, expected, result);
> > + ASSERT (expected.tv_sec =3D=3D result.tv_sec
> > + && expected.tv_nsec =3D=3D result.tv_nsec);
> > +
> >
> > /* TZ out of range should cause parse_datetime failure */
> > now.tv_sec =3D SOME_TIMEPOINT + 4711;
> Thanks for looking at this.
> This changes relative handling unfortunately:
>
> $ src/date --debug -d '2024-01-01 8:00:00PM -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed time part: 08:00:00pm UTC-05
> date: parsed relative part: +1 day(s)
> ...
> Wed 03 Jan 2024 01:00:00 GMT
>
> $ date --debug -d '2024-01-01 8:00:00PM -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed time part: 08:00:00pm
> date: parsed relative part: -5 day(s)
> ...
> Wed 27 Dec 2023 20:00:00 GMT
>
> Now there is an existing ambiguity here,
> where the AM/PM induces the relative interpretation:
>
> $ date --debug -d '2024-01-01 8:00:00PM -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed time part: 08:00:00pm
> date: parsed relative part: -5 day(s)
>
> $ date --debug -d '2024-01-01 8:00:00 -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed time part: 08:00:00 UTC-05
> date: parsed relative part: +1 day(s)
>
> BTW https://bugs.gnu.org/79078 was a recent bug report
> along the same lines of the relative part being unexpectedly
> considered as a timezone offset
>
> Now I agree we're already inconsistent in this regard, but I'm sure
> folks are relying on the AM/PM inducing a relative interpretation.
>
> If we were trying to make all this more consistent, IMHO
> we should change things so that we always interpret +|-<int>
> <days|minutes|...>
> as a relative adjustment, whereas your change does the opposite for the
> AM/PM case.
>
> cheers,
> Padraig
>
--000000000000f4e2b906443c8822
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Padraig,</div><div><br></div><div>Thanks for the f=
eedback.</div><div><br></div><div>I was able to get back to this and have a=
look at getting this inconsistency resolved, and I was able to find a chan=
ge that seems to resolve this inconsistency.</div><div><br></div><div>It is=
still correctly parsing the timezone with AM/PM:</div><div><br>$ ./src/dat=
e --debug -d '2024-01-01 8:00:00PM -0500'<br>date: parsed date part=
: (Y-M-D) 2024-01-01<br>date: parsed time part: 08:00:00pm UTC-05<br>date: =
input timezone: parsed date/time string (-05)<br>date: using specified time=
as starting value: '20:00:00'<br>date: starting date/time: '(Y=
-M-D) 2024-01-01 20:00:00 TZ=3D-05'<br>date: '(Y-M-D) 2024-01-01 20=
:00:00 TZ=3D-05' =3D 1704157200 epoch-seconds<br>date: timezone: system=
default<br>date: final: 1704157200.000000000 (epoch-seconds)<br>date: fina=
l: (Y-M-D) 2024-01-02 01:00:00 (UTC)<br>date: final: (Y-M-D) 2024-01-01 17:=
00:00 (UTC-08)<br>date: output format: =E2=80=98%a %d %b %Y %T %Z=E2=80=99<=
br>Mon 01 Jan 2024 17:00:00 PST</div><div><br></div><div>And will now corre=
ctly prioritize time offset with a ime unit is specified, both with AM/PM a=
nd without:</div><div><br></div><div>$ ./src/date --debug -d '2024-01-0=
1 8:00:00 -5 days'<br>date: parsed date part: (Y-M-D) 2024-01-01<br>dat=
e: parsed relative part: -5 day(s)<br>date: parsed time part: 08:00:00<br>d=
ate: input timezone: system default<br>date: using specified time as starti=
ng value: '08:00:00'<br>date: starting date/time: '(Y-M-D) 2024=
-01-01 08:00:00'<br>date: warning: when adding relative days, it is rec=
ommended to specify noon<br>date: after date adjustment (+0 years, +0 month=
s, -5 days),<br>date: =C2=A0 =C2=A0 new date/time =3D '(Y-M-D) 2023-12-=
27 08:00:00'<br>date: '(Y-M-D) 2023-12-27 08:00:00' =3D 1703692=
800 epoch-seconds<br>date: timezone: system default<br>date: final: 1703692=
800.000000000 (epoch-seconds)<br>date: final: (Y-M-D) 2023-12-27 16:00:00 (=
UTC)<br>date: final: (Y-M-D) 2023-12-27 08:00:00 (UTC-08)<br>date: output f=
ormat: =E2=80=98%a %d %b %Y %T %Z=E2=80=99<br>Wed 27 Dec 2023 08:00:00 PST<=
/div><div><br></div><div>$ ./src/date --debug -d '2024-01-01 8:00:00AM =
-5 days'<br>date: parsed date part: (Y-M-D) 2024-01-01<br>date: parsed =
relative part: -5 day(s)<br>date: parsed time part: 08:00:00<br>date: input=
timezone: system default<br>date: using specified time as starting value: =
'08:00:00'<br>date: starting date/time: '(Y-M-D) 2024-01-01 08:=
00:00'<br>date: warning: when adding relative days, it is recommended t=
o specify noon<br>date: after date adjustment (+0 years, +0 months, -5 days=
),<br>date: =C2=A0 =C2=A0 new date/time =3D '(Y-M-D) 2023-12-27 08:00:0=
0'<br>date: '(Y-M-D) 2023-12-27 08:00:00' =3D 1703692800 epoch-=
seconds<br>date: timezone: system default<br>date: final: 1703692800.000000=
000 (epoch-seconds)<br>date: final: (Y-M-D) 2023-12-27 16:00:00 (UTC)<br>da=
te: final: (Y-M-D) 2023-12-27 08:00:00 (UTC-08)<br>date: output format: =E2=
=80=98%a %d %b %Y %T %Z=E2=80=99<br>Wed 27 Dec 2023 08:00:00 PST</div><div>=
<br></div><div>And the coreutils complete testsuite is passing:</div><div><=
br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D<br>Testsuite summary for GNU coreutils 9.9.31-1d58e<br>=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br># TOT=
AL: 575<br># PASS: =C2=A0518<br># SKIP: =C2=A057<br># XFAIL: 0<br># FAIL: =
=C2=A00<br># XPASS: 0<br># ERROR: 0<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div><div><br></div><div>Below i=
s the full patch:</div><div><br></div><div>diff --git a/lib/parse-datetime.=
y b/lib/parse-datetime.y<br>index 6c52cd2c4c..71f8b9ae0e 100644<br>--- a/li=
b/parse-datetime.y<br>+++ b/lib/parse-datetime.y<br>@@ -573,8 +573,8 @@ deb=
ug_print_relative_time (char const *item, parser_control const *pc)<br>=C2=
=A0%parse-param { parser_control *pc }<br>=C2=A0%lex-param { parser_control=
*pc }<br>=C2=A0<br>-/* This grammar has 31 shift/reduce conflicts. =C2=A0*=
/<br>-%expect 31<br>+/* This grammar has 40 shift/reduce conflicts. =C2=A0*=
/<br>+%expect 40<br>=C2=A0<br>=C2=A0%union<br>=C2=A0{<br>@@ -681,17 +681,17=
@@ iso_8601_datetime:<br>=C2=A0 =C2=A0;<br>=C2=A0<br>=C2=A0time:<br>- =C2=
=A0 =C2=A0tUNUMBER tMERIDIAN<br>+ =C2=A0 =C2=A0tUNUMBER tMERIDIAN o_zone_of=
fset<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0s=
et_hhmmss (pc, $1.value, 0, 0, 0);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc-=
>meridian =3D $2;<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>- =C2=A0| tUNUMBER =
':' tUNUMBER tMERIDIAN<br>+ =C2=A0| tUNUMBER ':' tUNUMBER t=
MERIDIAN o_zone_offset<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0set_hhmmss (pc, $1.value, $3.value, 0, 0);<br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0pc->meridian =3D $4;<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0}<br>- =C2=A0| tUNUMBER ':' tUNUMBER ':' unsigned_second=
s tMERIDIAN<br>+ =C2=A0| tUNUMBER ':' tUNUMBER ':' unsigned=
_seconds tMERIDIAN o_zone_offset<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $=
5.tv_nsec);<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc->meridian =3D $6;<br=
>@@ -720,6 +720,11 @@ iso_8601_time:<br>=C2=A0o_zone_offset:<br>=C2=A0 =C2=
=A0/* empty */<br>=C2=A0 =C2=A0| zone_offset<br>+ =C2=A0| relunit_snumber<b=
r>+ =C2=A0 =C2=A0 =C2=A0{<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0if (! apply_relat=
ive_time (pc, $1, 1)) YYABORT;<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0debug_print_=
relative_time (_("relative"), pc);<br>+ =C2=A0 =C2=A0 =C2=A0}<br>=
=C2=A0 =C2=A0;<br>=C2=A0<br>=C2=A0zone_offset:<br>diff --git a/tests/test-p=
arse-datetime.c b/tests/test-parse-datetime.c<br>index 23c8598a6f..8bfb7210=
d6 100644<br>--- a/tests/test-parse-datetime.c<br>+++ b/tests/test-parse-da=
tetime.c<br>@@ -334,6 +334,31 @@ main (_GL_UNUSED int argc, char **argv)<br=
>=C2=A0 =C2=A0ASSERT (result.tv_sec =3D=3D result2.tv_sec<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0&& result.tv_nsec =3D=3D result2.tv_nsec=
);<br>=C2=A0<br>+ =C2=A0/* Check that timeone works with AM/PM */<br>+ =C2=
=A0p =3D "2024-01-01 8PM -08:00";<br>+ =C2=A0expected.tv_sec =3D =
1704168000;<br>+ =C2=A0expected.tv_nsec =3D 0;<br>+ =C2=A0ASSERT (parse_dat=
etime (&result, p, NULL));<br>+ =C2=A0LOG (p, expected, result);<br>+ =
=C2=A0ASSERT (expected.tv_sec =3D=3D result.tv_sec<br>+ =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0&& expected.tv_nsec =3D=3D result.tv_nsec);<br>+<b=
r>+ =C2=A0/* Check that date offset is preferred to timezone */<br>+ =C2=A0=
p =3D "2024-01-01 8PM -5 days";<br>+ =C2=A0expected.tv_sec =3D 17=
03725200;<br>+ =C2=A0expected.tv_nsec =3D 0;<br>+ =C2=A0ASSERT (parse_datet=
ime (&result, p, NULL));<br>+ =C2=A0LOG (p, expected, result);<br>+ =C2=
=A0ASSERT (expected.tv_sec =3D=3D result.tv_sec<br>+ =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0&& expected.tv_nsec =3D=3D result.tv_nsec);<br>+<br>+ =
=C2=A0p =3D "2024-01-01 20:00 -5 days";<br>+ =C2=A0expected.tv_se=
c =3D 1703725200;<br>+ =C2=A0expected.tv_nsec =3D 0;<br>+ =C2=A0ASSERT (par=
se_datetime (&result, p, NULL));<br>+ =C2=A0LOG (p, expected, result);<=
br>+ =C2=A0ASSERT (expected.tv_sec =3D=3D result.tv_sec<br>+ =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0&& expected.tv_nsec =3D=3D result.tv_nsec);<br>=
=C2=A0<br>=C2=A0 =C2=A0/* TZ out of range should cause parse_datetime failu=
re */<br>=C2=A0 =C2=A0now.tv_sec =3D SOME_TIMEPOINT + 4711;</div><div><br><=
/div><div>Regards.</div><div><br></div><div>Jeff</div></div><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Tue, 29 Jul 2025 at 04:22, P=C3=A1draig Brady <<a href=3D"mailto:P@=
draigbrady.com">P@HIDDEN</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On 29/07/2025 06:02, Jeffery Palm wrote:<b=
r>
> I took a look at this bug, and believe I have a patch that will resolv=
e it.<br>
> <br>
> $ ../src/date --debug -d '2024-01-01 8:00:00PM -0500'<br>
> date: parsed date part: (Y-M-D) 2024-01-01<br>
> date: parsed time part: 08:00:00pm UTC-05<br>
> date: input timezone: parsed date/time string (-05)<br>
> date: using specified time as starting value: '20:00:00'<br>
> date: starting date/time: '(Y-M-D) 2024-01-01 20:00:00 TZ=3D-05=
9;<br>
> date: '(Y-M-D) 2024-01-01 20:00:00 TZ=3D-05' =3D 1704157200 ep=
och-seconds<br>
> date: timezone: system default<br>
> date: final: 1704157200.000000000 (epoch-seconds)<br>
> date: final: (Y-M-D) 2024-01-02 01:00:00 (UTC)<br>
> date: final: (Y-M-D) 2024-01-01 17:00:00 (UTC-08)<br>
> date: output format: =E2=80=98%a %d %b %Y %T %Z=E2=80=99<br>
> Mon 01 Jan 2024 17:00:00 PST<br>
> <br>
> <br>
> And I was able to run the coreutils testsuite with no tests failing:<b=
r>
> <br>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<br>
> Testsuite summary for GNU coreutils 9.7.174-083f8<br>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<br>
> # TOTAL: 533<br>
> # PASS:=C2=A0 476<br>
> # SKIP:=C2=A0 57<br>
> # XFAIL: 0<br>
> # FAIL:=C2=A0 0<br>
> # XPASS: 0<br>
> # ERROR: 0<br>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<br>
> <br>
> Are there any other tests/changes I should consider for this?<br>
> <br>
> <br>
> Below is the patch for the changes I made for this, including a new<br=
>
> testcase for AM/PM with timezone.<br>
> <br>
> <br>
> --- a/lib/parse-datetime.y<br>
> +++ b/lib/parse-datetime.y<br>
> @@ -592,7 +592,7 @@ debug_print_relative_time (char const *item,<br>
> parser_control const *pc)<br>
>=C2=A0 =C2=A0%token tYEAR_UNIT tMONTH_UNIT tHOUR_UNIT tMINUTE_UNIT tSEC=
_UNIT<br>
>=C2=A0 =C2=A0%token <intval> tDAY_UNIT tDAY_SHIFT<br>
> <br>
> -%token <intval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN<br>
> +%token <intval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN tMERIDIAN_W=
ITH_ZONE<br>
>=C2=A0 =C2=A0%token <intval> tMONTH tORDINAL tZONE<br>
> <br>
>=C2=A0 =C2=A0%token <textintval> tSNUMBER tUNUMBER<br>
> @@ -698,6 +698,27 @@ time:<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0set_hhmmss (pc, $1.value, $3.v=
alue, $5.tv_sec, $5.tv_nsec);<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pc->meridian =3D $6;<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
> +=C2=A0 | tUNUMBER tMERIDIAN_WITH_ZONE tSNUMBER o_colon_minutes<br>
> +=C2=A0 =C2=A0 =C2=A0 {<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 set_hhmmss (pc, $1.value, 0, 0, 0);<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 pc->meridian =3D $2;<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 pc->zones_seen++;<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (! time_zone_hhmm (pc, $3, $4)) YYABOR=
T;<br>
> +=C2=A0 =C2=A0 =C2=A0 }<br>
> +=C2=A0 | tUNUMBER ':' tUNUMBER tMERIDIAN_WITH_ZONE tSNUMBER o=
_colon_minutes<br>
> +=C2=A0 =C2=A0 =C2=A0 {<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 set_hhmmss (pc, $1.value, $3.value, 0, 0)=
;<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 pc->meridian =3D $4;<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 pc->zones_seen++;<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (! time_zone_hhmm (pc, $5, $6)) YYABOR=
T;<br>
> +=C2=A0 =C2=A0 =C2=A0 }<br>
> +=C2=A0 | tUNUMBER ':' tUNUMBER ':' unsigned_seconds t=
MERIDIAN_WITH_ZONE<br>
> tSNUMBER o_colon_minutes<br>
> +=C2=A0 =C2=A0 =C2=A0 {<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 set_hhmmss (pc, $1.value, $3.value, $5.tv=
_sec, $5.tv_nsec);<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 pc->meridian =3D $6;<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 pc->zones_seen++;<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (! time_zone_hhmm (pc, $7, $8)) YYABOR=
T;<br>
> +=C2=A0 =C2=A0 =C2=A0 }<br>
>=C2=A0 =C2=A0 =C2=A0| iso_8601_time<br>
>=C2=A0 =C2=A0 =C2=A0;<br>
> <br>
> @@ -1527,14 +1548,19 @@ yylex (union YYSTYPE *lvalp, parser_control *p=
c)<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*p =3D '\0';<br=
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tp =3D lookup_word (pc,=
buff);<br>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (! tp)<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (tp)<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (debugging (pc))<=
br>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dbg_printf (_=
("error: unknown word '%s'\n"), buff);<br>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return '?';<=
br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lvalp->intval =3D=
tp->value;<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (tp->type =3D=
=3D tMERIDIAN)<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 char c=
onst *p =3D pc->input;<br>
<br>
Better to use a non shadowing name here ^<br>
<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 while =
(*p && c_isspace (*p))<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
p++;<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (*p=
=3D=3D '-' || *p =3D=3D '+')<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
return tMERIDIAN_WITH_ZONE;<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return tp->type;<=
br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lvalp->intval =3D tp->value;=
<br>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return tp->type;<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (c !=3D '(')<br>
> diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c=
<br>
> index 546b383c55..9766ed7a13 100644<br>
> --- a/tests/test-parse-datetime.c<br>
> +++ b/tests/test-parse-datetime.c<br>
> @@ -335,6 +335,15 @@ main (_GL_UNUSED int argc, char **argv)<br>
>=C2=A0 =C2=A0 =C2=A0ASSERT (result.tv_sec =3D=3D result2.tv_sec<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&& result.tv_ns=
ec =3D=3D result2.tv_nsec);<br>
> <br>
> +=C2=A0 /* Check that timeone works with AM/PM */<br>
> +=C2=A0 p =3D "2024-01-01 8PM -08:00";<br>
> +=C2=A0 expected.tv_sec =3D 1704168000;<br>
> +=C2=A0 expected.tv_nsec =3D 0;<br>
> +=C2=A0 ASSERT (parse_datetime (&result, p, NULL));<br>
> +=C2=A0 LOG (p, expected, result);<br>
> +=C2=A0 ASSERT (expected.tv_sec =3D=3D result.tv_sec<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 && expected.tv_nsec =3D=3D=
result.tv_nsec);<br>
> +<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0/* TZ out of range should cause parse_datetime fail=
ure */<br>
>=C2=A0 =C2=A0 =C2=A0now.tv_sec =3D SOME_TIMEPOINT + 4711;<br>
Thanks for looking at this.<br>
This changes relative handling unfortunately:<br>
<br>
=C2=A0 =C2=A0$ src/date --debug -d '2024-01-01 8:00:00PM -5 days'<b=
r>
=C2=A0 =C2=A0date: parsed date part: (Y-M-D) 2024-01-01<br>
=C2=A0 =C2=A0date: parsed time part: 08:00:00pm UTC-05<br>
=C2=A0 =C2=A0date: parsed relative part: +1 day(s)<br>
=C2=A0 =C2=A0...<br>
=C2=A0 =C2=A0Wed 03 Jan 2024 01:00:00 GMT<br>
<br>
=C2=A0 =C2=A0$ date --debug -d '2024-01-01 8:00:00PM -5 days'<br>
=C2=A0 =C2=A0date: parsed date part: (Y-M-D) 2024-01-01<br>
=C2=A0 =C2=A0date: parsed time part: 08:00:00pm<br>
=C2=A0 =C2=A0date: parsed relative part: -5 day(s)<br>
=C2=A0 =C2=A0...<br>
=C2=A0 =C2=A0Wed 27 Dec 2023 20:00:00 GMT<br>
<br>
Now there is an existing ambiguity here,<br>
where the AM/PM induces the relative interpretation:<br>
<br>
=C2=A0 =C2=A0$ date --debug -d '2024-01-01 8:00:00PM -5 days'<br>
=C2=A0 =C2=A0date: parsed date part: (Y-M-D) 2024-01-01<br>
=C2=A0 =C2=A0date: parsed time part: 08:00:00pm<br>
=C2=A0 =C2=A0date: parsed relative part: -5 day(s)<br>
<br>
=C2=A0 =C2=A0$ date --debug -d '2024-01-01 8:00:00 -5 days'<br>
=C2=A0 =C2=A0date: parsed date part: (Y-M-D) 2024-01-01<br>
=C2=A0 =C2=A0date: parsed time part: 08:00:00 UTC-05<br>
=C2=A0 =C2=A0date: parsed relative part: +1 day(s)<br>
<br>
BTW <a href=3D"https://bugs.gnu.org/79078" rel=3D"noreferrer" target=3D"_bl=
ank">https://bugs.gnu.org/79078</a> was a recent bug report<br>
along the same lines of the relative part being unexpectedly<br>
considered as a timezone offset<br>
<br>
Now I agree we're already inconsistent in this regard, but I'm sure=
<br>
folks are relying on the AM/PM inducing a relative interpretation.<br>
<br>
If we were trying to make all this more consistent, IMHO<br>
we should change things so that we always interpret +|-<int> <days=
|minutes|...><br>
as a relative adjustment, whereas your change does the opposite for the AM/=
PM case.<br>
<br>
cheers,<br>
Padraig<br>
</blockquote></div>
--000000000000f4e2b906443c8822--
X-Loop: help-debbugs@HIDDEN
Subject: bug#18328: can't say date -d '8pm -0500' though other combos work
Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 25 Nov 2025 20:23:10 +0000
Resent-Message-ID: <handler.18328.B18328.17641021884887 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 18328
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: confirmed
To: Jeffery Palm <palmje@HIDDEN>
Cc: 18328 <at> debbugs.gnu.org, Geoff Kuenning <geoff@HIDDEN>
Received: via spool by 18328-submit <at> debbugs.gnu.org id=B18328.17641021884887
(code B ref 18328); Tue, 25 Nov 2025 20:23:10 +0000
Received: (at 18328) by debbugs.gnu.org; 25 Nov 2025 20:23:08 +0000
Received: from localhost ([127.0.0.1]:41965 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vNzZ3-0001GL-LI
for submit <at> debbugs.gnu.org; Tue, 25 Nov 2025 15:23:07 -0500
Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:59866)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <pixelbeat@HIDDEN>)
id 1vNHR3-0005D5-O6
for 18328 <at> debbugs.gnu.org; Sun, 23 Nov 2025 16:15:55 -0500
Received: by mail-wm1-x336.google.com with SMTP id
5b1f17b1804b1-47118259fd8so31289465e9.3
for <18328 <at> debbugs.gnu.org>; Sun, 23 Nov 2025 13:15:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1763932547; x=1764537347; darn=debbugs.gnu.org;
h=in-reply-to:from:content-language:references:cc:to:subject
:user-agent:mime-version:date:message-id:sender:from:to:cc:subject
:date:message-id:reply-to;
bh=Q6fCM4Uic0TC5n1SFs9LC8rkUS0PKgrNtkrrOYjYrfA=;
b=XvDgzKTJAq+5UwkKgfP5CbHTNcbNcWZdE2GKKXmSiQR9g8G/c+REcHw227Z532wcml
ecDVMZgOdXK3Rt7W7a5GJ67X7lhYYcZabOzcV0VcaewmZtF4SO8KUN9wev/5X4C2h7Yk
GYAF7XCxThSegFdHwljr2R+BzBOJ95du588KAeDI+c12zafouFiPZCItVqfWlq7FqrM1
hst5nvUYpk70YxgbQuFldtehJkgHrngVT/yWZl1TLggZp/0IPLk/YyfWe1V5UITn7hh3
/6O4PoZ+bQsnV0FfdkSnrq2nWZvhcpEr9t8alvhZtwbahkC73FnChWJTqSWfpMaKORlT
Ovrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1763932547; x=1764537347;
h=in-reply-to:from:content-language:references:cc:to:subject
:user-agent:mime-version:date:message-id:sender:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=Q6fCM4Uic0TC5n1SFs9LC8rkUS0PKgrNtkrrOYjYrfA=;
b=YGgsz57S4aiLrRNa77+TPeGLG7fVLxCwfw1qY41FPgd+oruHljg8vqHIsQ2wB+srdC
KFfPL8T5YG9FKAFHmxL3Bhb5gm9gdAsXj5Oj1EzMM8Pr/Lii9utBAiyiCDguerMGdsaT
eO3PQrwxlzCgeMVRYn9A+IlZriqFSgQkLGPWSEHijUiQ0hTI1sCr5BYFnBm+EkK18dSc
TPBfdkrZw2tMQ1o/Vcq9pdPurjKZbUcGzPaHaHr4MRRc8a6Uj4eSftO+6dNStYopkCAY
Lc3h58DDgShTH+VwqMc4kR3VF34IIaWQiPvzaxVZvqA7akzGASsmvef02Ky3ioktyHDX
FvzA==
X-Gm-Message-State: AOJu0Yy0iSxjsx+KRhebhC66/0A7SjYh7LrDfEFZLzis3JN2RNG/2ncY
TXPcuGfqDo5kZiV48b/+K8y3wscvEyLyiJ/Iivis3SJftEK5YqPbrkcz
X-Gm-Gg: ASbGncsdtxksuQiAuHAPGSnxku7YefslErQPAY8Q90gpV5+kSa/1mha3+Psd9lPSmx9
1HGStQsjeuyuSg8+MUzzEZ0S6yKvWmhGkHNR6qsTXUKbvGbvcOXhw3tO7+wqngEMJl3JloQw0r6
PNzswqFXIuizzeQFUfEcLhszalZdnJ3tDOGAJdFPG7oaHTR3vxtuKkijkPWM71NFl7JCezKqVU9
FV1xdcHzGS6n78misBEPD/8ebeHuPGSX7wy8fLT42/bNL5z6w9pJ2/V5StYkuRu6G0rIhpVACzb
olJuWVvQu6pq8O6im7/0tGbzu4fN7euMopMRq/nBcAhpO1jJXxmujGbER3vthzWpJZZHNx+urJk
M8UP4WgxZEXv/xXexR6cS66gWT/uF73M7F3OhxZGPFWZuEGVShcE00uPGDyPzWj/o7zDYr/snBH
lSayyKzq8UvOx3RrOGhQPMGWPqRSUdczDKuUm4Mh7wYshBzpJ+eMM7nM1utfj//9otMLo=
X-Google-Smtp-Source: AGHT+IHytv2QHgVkpBqbT/C4tH5o6JQYEEq+HsDA3Gtq2144R/MpfdmFNO7rUP6aI+okbm6VE5oKpw==
X-Received: by 2002:a05:600c:3115:b0:477:b48d:ba7a with SMTP id
5b1f17b1804b1-477c01fd202mr91277455e9.32.1763932547181;
Sun, 23 Nov 2025 13:15:47 -0800 (PST)
Received: from [192.168.1.31]
(86-44-211-146-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.44.211.146])
by smtp.googlemail.com with ESMTPSA id
5b1f17b1804b1-477bf3aef57sm154200875e9.11.2025.11.23.13.15.45
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 23 Nov 2025 13:15:45 -0800 (PST)
Content-Type: multipart/mixed; boundary="------------bzofHtbiS4ZGRArU9TPS8B2Q"
Message-ID: <27b4305e-2153-4bec-8fd6-fd4aaedf6f3d@HIDDEN>
Date: Sun, 23 Nov 2025 21:15:44 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
References: <87ppfo36er.fsf@HIDDEN>
<CALPkt-PuUmx_Y=pp9W_7owS+qB7ULqo_vxgOpqt2jwA5W7SYmA@HIDDEN>
<3c15c4fd-de25-4333-aeb6-af70dd02e29a@HIDDEN>
<CALPkt-O0Yfd+3N78z9V3ZmXUR4s4x0OBtJv8NSZ0KLu4aN=AGg@HIDDEN>
Content-Language: en-US
From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
In-Reply-To: <CALPkt-O0Yfd+3N78z9V3ZmXUR4s4x0OBtJv8NSZ0KLu4aN=AGg@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------bzofHtbiS4ZGRArU9TPS8B2Q
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 23/11/2025 05:43, Jeffery Palm wrote:
> Hi Padraig,
>
> Thanks for the feedback.
>
> I was able to get back to this and have a look at getting this inconsistency resolved, and I was able to find a change that seems to resolve this inconsistency.
>
> It is still correctly parsing the timezone with AM/PM:
>
> $ ./src/date --debug -d '2024-01-01 8:00:00PM -0500'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed time part: 08:00:00pm UTC-05
> date: input timezone: parsed date/time string (-05)
> date: using specified time as starting value: '20:00:00'
> date: starting date/time: '(Y-M-D) 2024-01-01 20:00:00 TZ=-05'
> date: '(Y-M-D) 2024-01-01 20:00:00 TZ=-05' = 1704157200 epoch-seconds
> date: timezone: system default
> date: final: 1704157200.000000000 (epoch-seconds)
> date: final: (Y-M-D) 2024-01-02 01:00:00 (UTC)
> date: final: (Y-M-D) 2024-01-01 17:00:00 (UTC-08)
> date: output format: ‘%a %d %b %Y %T %Z’
> Mon 01 Jan 2024 17:00:00 PST
>
> And will now correctly prioritize time offset with a ime unit is specified, both with AM/PM and without:
>
> $ ./src/date --debug -d '2024-01-01 8:00:00 -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed relative part: -5 day(s)
> date: parsed time part: 08:00:00
> date: input timezone: system default
> date: using specified time as starting value: '08:00:00'
> date: starting date/time: '(Y-M-D) 2024-01-01 08:00:00'
> date: warning: when adding relative days, it is recommended to specify noon
> date: after date adjustment (+0 years, +0 months, -5 days),
> date: new date/time = '(Y-M-D) 2023-12-27 08:00:00'
> date: '(Y-M-D) 2023-12-27 08:00:00' = 1703692800 epoch-seconds
> date: timezone: system default
> date: final: 1703692800.000000000 (epoch-seconds)
> date: final: (Y-M-D) 2023-12-27 16:00:00 (UTC)
> date: final: (Y-M-D) 2023-12-27 08:00:00 (UTC-08)
> date: output format: ‘%a %d %b %Y %T %Z’
> Wed 27 Dec 2023 08:00:00 PST
>
> $ ./src/date --debug -d '2024-01-01 8:00:00AM -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed relative part: -5 day(s)
> date: parsed time part: 08:00:00
> date: input timezone: system default
> date: using specified time as starting value: '08:00:00'
> date: starting date/time: '(Y-M-D) 2024-01-01 08:00:00'
> date: warning: when adding relative days, it is recommended to specify noon
> date: after date adjustment (+0 years, +0 months, -5 days),
> date: new date/time = '(Y-M-D) 2023-12-27 08:00:00'
> date: '(Y-M-D) 2023-12-27 08:00:00' = 1703692800 epoch-seconds
> date: timezone: system default
> date: final: 1703692800.000000000 (epoch-seconds)
> date: final: (Y-M-D) 2023-12-27 16:00:00 (UTC)
> date: final: (Y-M-D) 2023-12-27 08:00:00 (UTC-08)
> date: output format: ‘%a %d %b %Y %T %Z’
> Wed 27 Dec 2023 08:00:00 PST
>
> And the coreutils complete testsuite is passing:
>
> ============================================================================
> Testsuite summary for GNU coreutils 9.9.31-1d58e
> ============================================================================
> # TOTAL: 575
> # PASS: 518
> # SKIP: 57
> # XFAIL: 0
> # FAIL: 0
> # XPASS: 0
> # ERROR: 0
> ============================================================================
>
> Below is the full patch:
>
> diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
> index 6c52cd2c4c..71f8b9ae0e 100644
> --- a/lib/parse-datetime.y
> +++ b/lib/parse-datetime.y
> @@ -573,8 +573,8 @@ debug_print_relative_time (char const *item, parser_control const *pc)
> %parse-param { parser_control *pc }
> %lex-param { parser_control *pc }
>
> -/* This grammar has 31 shift/reduce conflicts. */
> -%expect 31
> +/* This grammar has 40 shift/reduce conflicts. */
> +%expect 40
>
> %union
> {
> @@ -681,17 +681,17 @@ iso_8601_datetime:
> ;
>
> time:
> - tUNUMBER tMERIDIAN
> + tUNUMBER tMERIDIAN o_zone_offset
> {
> set_hhmmss (pc, $1.value, 0, 0, 0);
> pc->meridian = $2;
> }
> - | tUNUMBER ':' tUNUMBER tMERIDIAN
> + | tUNUMBER ':' tUNUMBER tMERIDIAN o_zone_offset
> {
> set_hhmmss (pc, $1.value, $3.value, 0, 0);
> pc->meridian = $4;
> }
> - | tUNUMBER ':' tUNUMBER ':' unsigned_seconds tMERIDIAN
> + | tUNUMBER ':' tUNUMBER ':' unsigned_seconds tMERIDIAN o_zone_offset
> {
> set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.tv_nsec);
> pc->meridian = $6;
> @@ -720,6 +720,11 @@ iso_8601_time:
> o_zone_offset:
> /* empty */
> | zone_offset
> + | relunit_snumber
> + {
> + if (! apply_relative_time (pc, $1, 1)) YYABORT;
> + debug_print_relative_time (_("relative"), pc);
> + }
> ;
>
> zone_offset:
> diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c
> index 23c8598a6f..8bfb7210d6 100644
> --- a/tests/test-parse-datetime.c
> +++ b/tests/test-parse-datetime.c
> @@ -334,6 +334,31 @@ main (_GL_UNUSED int argc, char **argv)
> ASSERT (result.tv_sec == result2.tv_sec
> && result.tv_nsec == result2.tv_nsec);
>
> + /* Check that timeone works with AM/PM */
> + p = "2024-01-01 8PM -08:00";
> + expected.tv_sec = 1704168000;
> + expected.tv_nsec = 0;
> + ASSERT (parse_datetime (&result, p, NULL));
> + LOG (p, expected, result);
> + ASSERT (expected.tv_sec == result.tv_sec
> + && expected.tv_nsec == result.tv_nsec);
> +
> + /* Check that date offset is preferred to timezone */
> + p = "2024-01-01 8PM -5 days";
> + expected.tv_sec = 1703725200;
> + expected.tv_nsec = 0;
> + ASSERT (parse_datetime (&result, p, NULL));
> + LOG (p, expected, result);
> + ASSERT (expected.tv_sec == result.tv_sec
> + && expected.tv_nsec == result.tv_nsec);
> +
> + p = "2024-01-01 20:00 -5 days";
> + expected.tv_sec = 1703725200;
> + expected.tv_nsec = 0;
> + ASSERT (parse_datetime (&result, p, NULL));
> + LOG (p, expected, result);
> + ASSERT (expected.tv_sec == result.tv_sec
> + && expected.tv_nsec == result.tv_nsec);
>
> /* TZ out of range should cause parse_datetime failure */
> now.tv_sec = SOME_TIMEPOINT + 4711;
>
> Regards.
>
> Jeff
>
> On Tue, 29 Jul 2025 at 04:22, Pádraig Brady <P@HIDDEN <mailto:P@HIDDEN>> wrote:
>
> On 29/07/2025 06:02, Jeffery Palm wrote:
> > I took a look at this bug, and believe I have a patch that will resolve it.
> >
> > $ ../src/date --debug -d '2024-01-01 8:00:00PM -0500'
> > date: parsed date part: (Y-M-D) 2024-01-01
> > date: parsed time part: 08:00:00pm UTC-05
> > date: input timezone: parsed date/time string (-05)
> > date: using specified time as starting value: '20:00:00'
> > date: starting date/time: '(Y-M-D) 2024-01-01 20:00:00 TZ=-05'
> > date: '(Y-M-D) 2024-01-01 20:00:00 TZ=-05' = 1704157200 epoch-seconds
> > date: timezone: system default
> > date: final: 1704157200.000000000 (epoch-seconds)
> > date: final: (Y-M-D) 2024-01-02 01:00:00 (UTC)
> > date: final: (Y-M-D) 2024-01-01 17:00:00 (UTC-08)
> > date: output format: ‘%a %d %b %Y %T %Z’
> > Mon 01 Jan 2024 17:00:00 PST
> >
> >
> > And I was able to run the coreutils testsuite with no tests failing:
> >
> > ============================================================================
> > Testsuite summary for GNU coreutils 9.7.174-083f8
> > ============================================================================
> > # TOTAL: 533
> > # PASS: 476
> > # SKIP: 57
> > # XFAIL: 0
> > # FAIL: 0
> > # XPASS: 0
> > # ERROR: 0
> > ============================================================================
> >
> > Are there any other tests/changes I should consider for this?
> >
> >
> > Below is the patch for the changes I made for this, including a new
> > testcase for AM/PM with timezone.
> >
> >
> > --- a/lib/parse-datetime.y
> > +++ b/lib/parse-datetime.y
> > @@ -592,7 +592,7 @@ debug_print_relative_time (char const *item,
> > parser_control const *pc)
> > %token tYEAR_UNIT tMONTH_UNIT tHOUR_UNIT tMINUTE_UNIT tSEC_UNIT
> > %token <intval> tDAY_UNIT tDAY_SHIFT
> >
> > -%token <intval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN
> > +%token <intval> tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN tMERIDIAN_WITH_ZONE
> > %token <intval> tMONTH tORDINAL tZONE
> >
> > %token <textintval> tSNUMBER tUNUMBER
> > @@ -698,6 +698,27 @@ time:
> > set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.tv_nsec);
> > pc->meridian = $6;
> > }
> > + | tUNUMBER tMERIDIAN_WITH_ZONE tSNUMBER o_colon_minutes
> > + {
> > + set_hhmmss (pc, $1.value, 0, 0, 0);
> > + pc->meridian = $2;
> > + pc->zones_seen++;
> > + if (! time_zone_hhmm (pc, $3, $4)) YYABORT;
> > + }
> > + | tUNUMBER ':' tUNUMBER tMERIDIAN_WITH_ZONE tSNUMBER o_colon_minutes
> > + {
> > + set_hhmmss (pc, $1.value, $3.value, 0, 0);
> > + pc->meridian = $4;
> > + pc->zones_seen++;
> > + if (! time_zone_hhmm (pc, $5, $6)) YYABORT;
> > + }
> > + | tUNUMBER ':' tUNUMBER ':' unsigned_seconds tMERIDIAN_WITH_ZONE
> > tSNUMBER o_colon_minutes
> > + {
> > + set_hhmmss (pc, $1.value, $3.value, $5.tv_sec, $5.tv_nsec);
> > + pc->meridian = $6;
> > + pc->zones_seen++;
> > + if (! time_zone_hhmm (pc, $7, $8)) YYABORT;
> > + }
> > | iso_8601_time
> > ;
> >
> > @@ -1527,14 +1548,19 @@ yylex (union YYSTYPE *lvalp, parser_control *pc)
> >
> > *p = '\0';
> > tp = lookup_word (pc, buff);
> > - if (! tp)
> > + if (tp)
> > {
> > - if (debugging (pc))
> > - dbg_printf (_("error: unknown word '%s'\n"), buff);
> > - return '?';
> > + lvalp->intval = tp->value;
> > + if (tp->type == tMERIDIAN)
> > + {
> > + char const *p = pc->input;
>
> Better to use a non shadowing name here ^
>
> > + while (*p && c_isspace (*p))
> > + p++;
> > + if (*p == '-' || *p == '+')
> > + return tMERIDIAN_WITH_ZONE;
> > + }
> > + return tp->type;
> > }
> > - lvalp->intval = tp->value;
> > - return tp->type;
> > }
> >
> > if (c != '(')
> > diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c
> > index 546b383c55..9766ed7a13 100644
> > --- a/tests/test-parse-datetime.c
> > +++ b/tests/test-parse-datetime.c
> > @@ -335,6 +335,15 @@ main (_GL_UNUSED int argc, char **argv)
> > ASSERT (result.tv_sec == result2.tv_sec
> > && result.tv_nsec == result2.tv_nsec);
> >
> > + /* Check that timeone works with AM/PM */
> > + p = "2024-01-01 8PM -08:00";
> > + expected.tv_sec = 1704168000;
> > + expected.tv_nsec = 0;
> > + ASSERT (parse_datetime (&result, p, NULL));
> > + LOG (p, expected, result);
> > + ASSERT (expected.tv_sec == result.tv_sec
> > + && expected.tv_nsec == result.tv_nsec);
> > +
> >
> > /* TZ out of range should cause parse_datetime failure */
> > now.tv_sec = SOME_TIMEPOINT + 4711;
> Thanks for looking at this.
> This changes relative handling unfortunately:
>
> $ src/date --debug -d '2024-01-01 8:00:00PM -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed time part: 08:00:00pm UTC-05
> date: parsed relative part: +1 day(s)
> ...
> Wed 03 Jan 2024 01:00:00 GMT
>
> $ date --debug -d '2024-01-01 8:00:00PM -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed time part: 08:00:00pm
> date: parsed relative part: -5 day(s)
> ...
> Wed 27 Dec 2023 20:00:00 GMT
>
> Now there is an existing ambiguity here,
> where the AM/PM induces the relative interpretation:
>
> $ date --debug -d '2024-01-01 8:00:00PM -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed time part: 08:00:00pm
> date: parsed relative part: -5 day(s)
>
> $ date --debug -d '2024-01-01 8:00:00 -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed time part: 08:00:00 UTC-05
> date: parsed relative part: +1 day(s)
>
> BTW https://bugs.gnu.org/79078 <https://bugs.gnu.org/79078> was a recent bug report
> along the same lines of the relative part being unexpectedly
> considered as a timezone offset
>
> Now I agree we're already inconsistent in this regard, but I'm sure
> folks are relying on the AM/PM inducing a relative interpretation.
>
> If we were trying to make all this more consistent, IMHO
> we should change things so that we always interpret +|-<int> <days|minutes|...>
> as a relative adjustment, whereas your change does the opposite for the AM/PM case.
Thanks for looking at this again.
I've attached the diff in case others want to more easily test.
I see that the unadorned number is still taken as a timezone which is good
for compat (and would be good to add to tests I think):
$ src/date --debug -d '2024-01-01 20:00 -5'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed time part: 20:00:00 UTC-05
thanks,
Padraig
--------------bzofHtbiS4ZGRArU9TPS8B2Q
Content-Type: text/x-patch; charset=UTF-8; name="parse-datetime-relative.diff"
Content-Disposition: attachment; filename="parse-datetime-relative.diff"
Content-Transfer-Encoding: base64
ZGlmZiAtLWdpdCBhL2xpYi9wYXJzZS1kYXRldGltZS55IGIvbGliL3BhcnNlLWRhdGV0aW1l
LnkKaW5kZXggNmM1MmNkMmM0Yy4uNzFmOGI5YWUwZSAxMDA2NDQKLS0tIGEvbGliL3BhcnNl
LWRhdGV0aW1lLnkKKysrIGIvbGliL3BhcnNlLWRhdGV0aW1lLnkKQEAgLTU3Myw4ICs1NzMs
OCBAQCBkZWJ1Z19wcmludF9yZWxhdGl2ZV90aW1lIChjaGFyIGNvbnN0ICppdGVtLCBwYXJz
ZXJfY29udHJvbCBjb25zdCAqcGMpCiAlcGFyc2UtcGFyYW0geyBwYXJzZXJfY29udHJvbCAq
cGMgfQogJWxleC1wYXJhbSB7IHBhcnNlcl9jb250cm9sICpwYyB9CgotLyogVGhpcyBncmFt
bWFyIGhhcyAzMSBzaGlmdC9yZWR1Y2UgY29uZmxpY3RzLiAgKi8KLSVleHBlY3QgMzEKKy8q
IFRoaXMgZ3JhbW1hciBoYXMgNDAgc2hpZnQvcmVkdWNlIGNvbmZsaWN0cy4gICovCislZXhw
ZWN0IDQwCgogJXVuaW9uCiB7CkBAIC02ODEsMTcgKzY4MSwxNyBAQCBpc29fODYwMV9kYXRl
dGltZToKICAgOwoKIHRpbWU6Ci0gICAgdFVOVU1CRVIgdE1FUklESUFOCisgICAgdFVOVU1C
RVIgdE1FUklESUFOIG9fem9uZV9vZmZzZXQKICAgICAgIHsKICAgICAgICAgc2V0X2hobW1z
cyAocGMsICQxLnZhbHVlLCAwLCAwLCAwKTsKICAgICAgICAgcGMtPm1lcmlkaWFuID0gJDI7
CiAgICAgICB9Ci0gIHwgdFVOVU1CRVIgJzonIHRVTlVNQkVSIHRNRVJJRElBTgorICB8IHRV
TlVNQkVSICc6JyB0VU5VTUJFUiB0TUVSSURJQU4gb196b25lX29mZnNldAogICAgICAgewog
ICAgICAgICBzZXRfaGhtbXNzIChwYywgJDEudmFsdWUsICQzLnZhbHVlLCAwLCAwKTsKICAg
ICAgICAgcGMtPm1lcmlkaWFuID0gJDQ7CiAgICAgICB9Ci0gIHwgdFVOVU1CRVIgJzonIHRV
TlVNQkVSICc6JyB1bnNpZ25lZF9zZWNvbmRzIHRNRVJJRElBTgorICB8IHRVTlVNQkVSICc6
JyB0VU5VTUJFUiAnOicgdW5zaWduZWRfc2Vjb25kcyB0TUVSSURJQU4gb196b25lX29mZnNl
dAogICAgICAgewogICAgICAgICBzZXRfaGhtbXNzIChwYywgJDEudmFsdWUsICQzLnZhbHVl
LCAkNS50dl9zZWMsICQ1LnR2X25zZWMpOwogICAgICAgICBwYy0+bWVyaWRpYW4gPSAkNjsK
QEAgLTcyMCw2ICs3MjAsMTEgQEAgaXNvXzg2MDFfdGltZToKIG9fem9uZV9vZmZzZXQ6CiAg
IC8qIGVtcHR5ICovCiAgIHwgem9uZV9vZmZzZXQKKyAgfCByZWx1bml0X3NudW1iZXIKKyAg
ICAgIHsKKyAgICAgICAgaWYgKCEgYXBwbHlfcmVsYXRpdmVfdGltZSAocGMsICQxLCAxKSkg
WVlBQk9SVDsKKyAgICAgICAgZGVidWdfcHJpbnRfcmVsYXRpdmVfdGltZSAoXygicmVsYXRp
dmUiKSwgcGMpOworICAgICAgfQogICA7Cgogem9uZV9vZmZzZXQ6Cg==
--------------bzofHtbiS4ZGRArU9TPS8B2Q--
X-Loop: help-debbugs@HIDDEN
Subject: bug#18328: can't say date -d '8pm -0500' though other combos work
Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 25 Nov 2025 20:32:05 +0000
Resent-Message-ID: <handler.18328.B18328.176410271318751 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 18328
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: confirmed
To: Jeffery Palm <palmje@HIDDEN>
Cc: 18328 <at> debbugs.gnu.org, bug-gnulib <bug-gnulib@HIDDEN>, Geoff Kuenning <geoff@HIDDEN>
Received: via spool by 18328-submit <at> debbugs.gnu.org id=B18328.176410271318751
(code B ref 18328); Tue, 25 Nov 2025 20:32:05 +0000
Received: (at 18328) by debbugs.gnu.org; 25 Nov 2025 20:31:53 +0000
Received: from localhost ([127.0.0.1]:42322 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vNzhY-0004rv-PK
for submit <at> debbugs.gnu.org; Tue, 25 Nov 2025 15:31:53 -0500
Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:59680)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <pixelbeat@HIDDEN>)
id 1vNHmi-0006Ee-D3
for 18328 <at> debbugs.gnu.org; Sun, 23 Nov 2025 16:38:17 -0500
Received: by mail-wm1-x330.google.com with SMTP id
5b1f17b1804b1-47118259fd8so31344245e9.3
for <18328 <at> debbugs.gnu.org>; Sun, 23 Nov 2025 13:38:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1763933890; x=1764538690; darn=debbugs.gnu.org;
h=in-reply-to:from:content-language:references:cc:to:subject
:user-agent:mime-version:date:message-id:sender:from:to:cc:subject
:date:message-id:reply-to;
bh=g7AWELhAhNRyBjU+PYuO4FyDNf8wQk3hgmiVDcQplJU=;
b=LgK5qE7EekjU6iI9d5VyrYfxDodVJDPz69tweFBAI/iQTcO0yznk3QFaAD0zDiobL+
hpsilSDWXNaoe9qx+uxLXssiwPyRTZTgZepT8ZjTOedQRM5lwdIDD2TbEQGJlsXn0/Wq
EP0y161RlAgzZyq0IBs/CvN5ZhPGcgYzg0O8LInsWtyf60BhImWZGUMN2EFc5aQ9D/TF
N6qtwMYm4+0jVuGAEY5ACPSRJfqbzj3d9DNGzk1wXiC6Bt7PE3aAPi3dtmC+3IolIS4w
QUJNLnot41YX+rrOfX0khh9bdv69IZ0n1mc6fLZD6jLo7pfWNvlBm5bzk19Tc9ohm/2p
yHtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1763933890; x=1764538690;
h=in-reply-to:from:content-language:references:cc:to:subject
:user-agent:mime-version:date:message-id:sender:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=g7AWELhAhNRyBjU+PYuO4FyDNf8wQk3hgmiVDcQplJU=;
b=ZaCoV0TyMTmttYS3CcVCQ9ydkWDeq6SKh0A7BZjAU1ZIXbFRfdAgiJ3zvuLYb61nkT
qxvSXLEElkbNFj4KsApWB+kKCXYdoRBFQvzKczv80xfiNm0KoDp5+Q+4/hZ+UN9bdrW0
sAVY6H/L68S40DFl5/IIzTD8+d5L55wrH66MjnZWXkYz/5CLuey8lkBVdK5oevgWrwWa
7Yr5MPGSZqya/HckaYsNGRdFfEMoKLxr9Y1jitQB7MKhYtoNxzu4Amb5hEc4PddcEW3W
9V3eKQM8KU45K/SIF1hsZtFmRc8dO6KP8OFAL3MfVtFeHbljDP51qQtAkj4G9teg7IwT
SzVg==
X-Gm-Message-State: AOJu0YwseVEs0H14jhRd+E8ZkbnNdzxvaW5Tv32RUoj7dFkRcuRX/liV
GJBtnnSr/yOgXxM93Nc+g0t3Vab5bfg+Axc8+K6K82l/VskUZp3i9Wrj
X-Gm-Gg: ASbGncubainN/4arvIWTZPuKJV2SsLeGChT9/u1716CmC1gytOR++hmQ749U5jrH+ez
AIKweYfYQrXKuAmxirhfOARqwKMEi/rzYZmQKNvV+sIhj7igF5UQVvlacMrTba3f8gM6QV71Ya6
vUmzau8gYHt0IFRzwTFSoD8o4Stq2a5meALrYyn1eW7FtLi+iz1RXkBvD4d+zv5e+tL3MCZtDKW
nIGFvxrtivWl7A4CO2kOCGcxxlEL1calqDhZESqMMPCyqwQ/F8+12rDEPaEpUMAtksqVkxdcU0a
N2YVR54EZ9b9IiyjYMxQFIOt+7Y2REbLsWrLBCI2ZaqEQUreuT3TDPDSIdsZ/5kX9Jz5eXNznMa
KIs1NKKfGoEQcOB+6Pa6C3nponD8EM61iA09lwskHwLb2BLPLUr6c2rYanNecQ1aogXwEEUjnym
FXvI+92um/Mmu0lRXD55w8BSYrW3Hpsn+ehfK9dnG8b7w3UWCsXWWQfs+9OXfFHZfHwGjtBmdkw
B11OA==
X-Google-Smtp-Source: AGHT+IHlPZicUfqs7VttQnVYjoIc0sZksLz/Cw+Vymdp4KJR58hm0B5ybMsgwpU5saYf3upUK3oABQ==
X-Received: by 2002:a05:600c:4f88:b0:477:942:7521 with SMTP id
5b1f17b1804b1-477c018afa2mr95719655e9.14.1763933889739;
Sun, 23 Nov 2025 13:38:09 -0800 (PST)
Received: from [192.168.1.31]
(86-44-211-146-dynamic.agg2.lod.rsl-rtd.eircom.net. [86.44.211.146])
by smtp.googlemail.com with ESMTPSA id
ffacd0b85a97d-42cb7fa3a6bsm24536548f8f.28.2025.11.23.13.38.08
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Sun, 23 Nov 2025 13:38:09 -0800 (PST)
Content-Type: multipart/mixed; boundary="------------sYEPf2lZ4Idtf0wjkMjSx6ZB"
Message-ID: <9da2b80c-5e8d-4ddf-bbc0-0c3422770908@HIDDEN>
Date: Sun, 23 Nov 2025 21:38:07 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird Beta
References: <87ppfo36er.fsf@HIDDEN>
<CALPkt-PuUmx_Y=pp9W_7owS+qB7ULqo_vxgOpqt2jwA5W7SYmA@HIDDEN>
<3c15c4fd-de25-4333-aeb6-af70dd02e29a@HIDDEN>
<CALPkt-O0Yfd+3N78z9V3ZmXUR4s4x0OBtJv8NSZ0KLu4aN=AGg@HIDDEN>
Content-Language: en-US
From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
In-Reply-To: <CALPkt-O0Yfd+3N78z9V3ZmXUR4s4x0OBtJv8NSZ0KLu4aN=AGg@HIDDEN>
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
This is a multi-part message in MIME format.
--------------sYEPf2lZ4Idtf0wjkMjSx6ZB
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
On 23/11/2025 05:43, Jeffery Palm wrote:
> Hi Padraig,
>
> Thanks for the feedback.
>
> I was able to get back to this and have a look at getting this inconsistency resolved, and I was able to find a change that seems to resolve this inconsistency.
>
> It is still correctly parsing the timezone with AM/PM:
>
> $ ./src/date --debug -d '2024-01-01 8:00:00PM -0500'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed time part: 08:00:00pm UTC-05
> date: input timezone: parsed date/time string (-05)
> date: using specified time as starting value: '20:00:00'
> date: starting date/time: '(Y-M-D) 2024-01-01 20:00:00 TZ=-05'
> date: '(Y-M-D) 2024-01-01 20:00:00 TZ=-05' = 1704157200 epoch-seconds
> date: timezone: system default
> date: final: 1704157200.000000000 (epoch-seconds)
> date: final: (Y-M-D) 2024-01-02 01:00:00 (UTC)
> date: final: (Y-M-D) 2024-01-01 17:00:00 (UTC-08)
> date: output format: ‘%a %d %b %Y %T %Z’
> Mon 01 Jan 2024 17:00:00 PST
>
> And will now correctly prioritize time offset with a ime unit is specified, both with AM/PM and without:
>
> $ ./src/date --debug -d '2024-01-01 8:00:00 -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed relative part: -5 day(s)
> date: parsed time part: 08:00:00
> date: input timezone: system default
> date: using specified time as starting value: '08:00:00'
> date: starting date/time: '(Y-M-D) 2024-01-01 08:00:00'
> date: warning: when adding relative days, it is recommended to specify noon
> date: after date adjustment (+0 years, +0 months, -5 days),
> date: new date/time = '(Y-M-D) 2023-12-27 08:00:00'
> date: '(Y-M-D) 2023-12-27 08:00:00' = 1703692800 epoch-seconds
> date: timezone: system default
> date: final: 1703692800.000000000 (epoch-seconds)
> date: final: (Y-M-D) 2023-12-27 16:00:00 (UTC)
> date: final: (Y-M-D) 2023-12-27 08:00:00 (UTC-08)
> date: output format: ‘%a %d %b %Y %T %Z’
> Wed 27 Dec 2023 08:00:00 PST
>
> $ ./src/date --debug -d '2024-01-01 8:00:00AM -5 days'
> date: parsed date part: (Y-M-D) 2024-01-01
> date: parsed relative part: -5 day(s)
> date: parsed time part: 08:00:00
> date: input timezone: system default
> date: using specified time as starting value: '08:00:00'
> date: starting date/time: '(Y-M-D) 2024-01-01 08:00:00'
> date: warning: when adding relative days, it is recommended to specify noon
> date: after date adjustment (+0 years, +0 months, -5 days),
> date: new date/time = '(Y-M-D) 2023-12-27 08:00:00'
> date: '(Y-M-D) 2023-12-27 08:00:00' = 1703692800 epoch-seconds
> date: timezone: system default
> date: final: 1703692800.000000000 (epoch-seconds)
> date: final: (Y-M-D) 2023-12-27 16:00:00 (UTC)
> date: final: (Y-M-D) 2023-12-27 08:00:00 (UTC-08)
> date: output format: ‘%a %d %b %Y %T %Z’
> Wed 27 Dec 2023 08:00:00 PST
>
> And the coreutils complete testsuite is passing:
>
> Below is the full patch:
I've attached the patch for easier application if others want to test.
Also CC'd bug-gnulib as that's where the codes originates.
I see that the unadorned number is still taken as a timezone which is good
for compat (and would be good to add to tests I think):
$ src/date --debug -d '2024-01-01 20:00 -5'
date: parsed date part: (Y-M-D) 2024-01-01
date: parsed time part: 20:00:00 UTC-05
cheers,
Padraig
--------------sYEPf2lZ4Idtf0wjkMjSx6ZB
Content-Type: text/x-patch; charset=UTF-8; name="parse-datetime-relative.diff"
Content-Disposition: attachment; filename="parse-datetime-relative.diff"
Content-Transfer-Encoding: base64
ZGlmZiAtLWdpdCBhL2xpYi9wYXJzZS1kYXRldGltZS55IGIvbGliL3BhcnNlLWRhdGV0aW1l
LnkKaW5kZXggNmM1MmNkMmM0Yy4uNzFmOGI5YWUwZSAxMDA2NDQKLS0tIGEvbGliL3BhcnNl
LWRhdGV0aW1lLnkKKysrIGIvbGliL3BhcnNlLWRhdGV0aW1lLnkKQEAgLTU3Myw4ICs1NzMs
OCBAQCBkZWJ1Z19wcmludF9yZWxhdGl2ZV90aW1lIChjaGFyIGNvbnN0ICppdGVtLCBwYXJz
ZXJfY29udHJvbCBjb25zdCAqcGMpCiAlcGFyc2UtcGFyYW0geyBwYXJzZXJfY29udHJvbCAq
cGMgfQogJWxleC1wYXJhbSB7IHBhcnNlcl9jb250cm9sICpwYyB9CgotLyogVGhpcyBncmFt
bWFyIGhhcyAzMSBzaGlmdC9yZWR1Y2UgY29uZmxpY3RzLiAgKi8KLSVleHBlY3QgMzEKKy8q
IFRoaXMgZ3JhbW1hciBoYXMgNDAgc2hpZnQvcmVkdWNlIGNvbmZsaWN0cy4gICovCislZXhw
ZWN0IDQwCgogJXVuaW9uCiB7CkBAIC02ODEsMTcgKzY4MSwxNyBAQCBpc29fODYwMV9kYXRl
dGltZToKICAgOwoKIHRpbWU6Ci0gICAgdFVOVU1CRVIgdE1FUklESUFOCisgICAgdFVOVU1C
RVIgdE1FUklESUFOIG9fem9uZV9vZmZzZXQKICAgICAgIHsKICAgICAgICAgc2V0X2hobW1z
cyAocGMsICQxLnZhbHVlLCAwLCAwLCAwKTsKICAgICAgICAgcGMtPm1lcmlkaWFuID0gJDI7
CiAgICAgICB9Ci0gIHwgdFVOVU1CRVIgJzonIHRVTlVNQkVSIHRNRVJJRElBTgorICB8IHRV
TlVNQkVSICc6JyB0VU5VTUJFUiB0TUVSSURJQU4gb196b25lX29mZnNldAogICAgICAgewog
ICAgICAgICBzZXRfaGhtbXNzIChwYywgJDEudmFsdWUsICQzLnZhbHVlLCAwLCAwKTsKICAg
ICAgICAgcGMtPm1lcmlkaWFuID0gJDQ7CiAgICAgICB9Ci0gIHwgdFVOVU1CRVIgJzonIHRV
TlVNQkVSICc6JyB1bnNpZ25lZF9zZWNvbmRzIHRNRVJJRElBTgorICB8IHRVTlVNQkVSICc6
JyB0VU5VTUJFUiAnOicgdW5zaWduZWRfc2Vjb25kcyB0TUVSSURJQU4gb196b25lX29mZnNl
dAogICAgICAgewogICAgICAgICBzZXRfaGhtbXNzIChwYywgJDEudmFsdWUsICQzLnZhbHVl
LCAkNS50dl9zZWMsICQ1LnR2X25zZWMpOwogICAgICAgICBwYy0+bWVyaWRpYW4gPSAkNjsK
QEAgLTcyMCw2ICs3MjAsMTEgQEAgaXNvXzg2MDFfdGltZToKIG9fem9uZV9vZmZzZXQ6CiAg
IC8qIGVtcHR5ICovCiAgIHwgem9uZV9vZmZzZXQKKyAgfCByZWx1bml0X3NudW1iZXIKKyAg
ICAgIHsKKyAgICAgICAgaWYgKCEgYXBwbHlfcmVsYXRpdmVfdGltZSAocGMsICQxLCAxKSkg
WVlBQk9SVDsKKyAgICAgICAgZGVidWdfcHJpbnRfcmVsYXRpdmVfdGltZSAoXygicmVsYXRp
dmUiKSwgcGMpOworICAgICAgfQogICA7Cgogem9uZV9vZmZzZXQ6Cg==
--------------sYEPf2lZ4Idtf0wjkMjSx6ZB--
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.