Received: (at 18328) by debbugs.gnu.org; 25 Nov 2025 20:31:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 25 15:31:53 2025
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
Subject: Re: bug#18328: can't say date -d '8pm -0500' though other combos work
To: Jeffery Palm <palmje@HIDDEN>
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-Debbugs-Envelope-To: 18328
Cc: 18328 <at> debbugs.gnu.org, bug-gnulib <bug-gnulib@HIDDEN>,
Geoff Kuenning <geoff@HIDDEN>
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--
bug-coreutils@HIDDEN:bug#18328; Package coreutils.
Full text available.
Received: (at 18328) by debbugs.gnu.org; 25 Nov 2025 20:23:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 25 15:23:07 2025
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
Subject: Re: bug#18328: can't say date -d '8pm -0500' though other combos work
To: Jeffery Palm <palmje@HIDDEN>
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-Debbugs-Envelope-To: 18328
Cc: 18328 <at> debbugs.gnu.org, Geoff Kuenning <geoff@HIDDEN>
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--
bug-coreutils@HIDDEN:bug#18328; Package coreutils.
Full text available.
Received: (at 18328) by debbugs.gnu.org; 25 Nov 2025 20:22:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 25 15:22:13 2025
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>
Subject: Re: bug#18328: can't say date -d '8pm -0500' though other combos work
To: P@HIDDEN
Content-Type: multipart/alternative; boundary="000000000000f4e2b906443c8822"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 18328
Cc: 18328 <at> debbugs.gnu.org, Geoff Kuenning <geoff@HIDDEN>
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--
bug-coreutils@HIDDEN:bug#18328; Package coreutils.
Full text available.
Received: (at 18328) by debbugs.gnu.org; 29 Jul 2025 11:22:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 29 07:22:44 2025
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
Subject: Re: bug#18328: can't say date -d '8pm -0500' though other combos work
To: Jeffery Palm <palmje@HIDDEN>, 18328 <at> debbugs.gnu.org
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-Debbugs-Envelope-To: 18328
Cc: Geoff Kuenning <geoff@HIDDEN>
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
bug-coreutils@HIDDEN:bug#18328; Package coreutils.
Full text available.
Received: (at 18328) by debbugs.gnu.org; 29 Jul 2025 05:15:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 29 01:15:09 2025
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>
Subject: Re: bug#18328: can't say date -d '8pm -0500' though other combos work
To: 18328 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary="0000000000007560d4063b0a51ea"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 18328
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--
bug-coreutils@HIDDEN:bug#18328; Package coreutils.
Full text available.Received: (at 18328) by debbugs.gnu.org; 20 Oct 2018 06:30:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 20 02:30:34 2018 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?B?56mN5Li55bC8?= Dan Jacobson <jidanni@HIDDEN> To: Assaf Gordon <assafgordon@HIDDEN> Subject: Re: bug#18328: can't say date -d '8pm -0500' though other combos work 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-Debbugs-Envelope-To: 18328 Cc: 18328 <at> debbugs.gnu.org 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.
bug-coreutils@HIDDEN:bug#18328; Package coreutils.
Full text available.Assaf Gordon <assafgordon@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Assaf Gordon <assafgordon@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 18328) 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]: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) 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: 18328 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
bug-coreutils@HIDDEN:bug#18328; Package coreutils.
Full text available.Received: (at submit) by debbugs.gnu.org; 25 Aug 2014 16:01:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Aug 25 12:01:58 2014 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?B?56mN5Li55bC8?= Dan Jacobson <jidanni@HIDDEN> To: bug-coreutils@HIDDEN Subject: can't say date -d '8pm -0500' though other combos work 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-Debbugs-Envelope-To: submit 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
積丹尼 Dan Jacobson <jidanni@HIDDEN>:bug-coreutils@HIDDEN.
Full text available.bug-coreutils@HIDDEN:bug#18328; Package coreutils.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.