GNU bug report logs - #73510
Questions on date command.

Previous Next

To reply to this bug, email your comments to 73510 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Benjamin Vargin <benjamin.vargin.dev <at> proton.me>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: Questions on date command.
Date: Fri, 27 Sep 2024 07:18:43 +0000

[Message part 1 (text/plain, inline)]

Hello,

First of all, I would like to thank you for all the works accomplished by your teams !!

I'm currently implementing functions in bash which are using the command "date".
I have noticed something strange when I realize manipulation during the daylight saving from Winter to Summer times in Europe.

Let me know, if it's the good place to submit my question or where I could do it.

In France, this year (2024), we have changed time during the night between the 30th and 31st of March.
At 2.00 AM (31st march) -- it was --> 3.00 AM (31st march)

So if I do the date operation 30th march 2.30AM + 1 day, I'm expecting something like 31st march 3.30AM.

Observation using containers: bash - date (GNU coreutils) 9.5
$ docker run --rm -it docker.io/bash:5.2.32
$ apk update
$ apk add --no-cache coreutils tzdata
$ date --version
date (GNU coreutils) 9.5
$ export TZ="Europe/Paris"
$ date -d "2024-03-30T02:30:00.123+0100 + 1 days" "+%FT%T.%3N%z"
2024-03-31T01:30:00.123+0100

$ date -d "2024-03-30T02:30:00.123+0100 + 24 hours" "+%FT%T.%3N%z"
2024-03-31T03:30:00.123+0200

# Minus looks fine
$ date -d "2024-03-31T03:30:00.123+0200 - 1 days" "+%FT%T.%3N%z"

2024-03-30T02:30:00.123+0100

$ date -d "2024-03-31T03:30:00.123+0200 - 24 hours" "+%FT%T.%3N%z"
2024-03-30T02:30:00.123+0100

The logic behind this is that the 31st is a day with 23 hours only, so 1 day was considered as 23 hours even if we didn't include all this day.
$ date -d "2024-03-30T02:30:00.123+0100 + 23 hours" "+%FT%T.%3N%z"
2024-03-31T01:30:00.123+0100

This behavior could be understood when we are taking a more simple case (that's the current result):
2024-03-30T13:30:00.123+0100 + 1 day => 2024-03-30T14:30:00.123+0200
But I understand less when we fall in the time shift window.

Question 1: Should 3.30AM be the good result to the operation "2024-03-30T02:30:00.123+0100 + 1 days" ?

In addition, I have tested on other virtual environments (sorry I don't have a native one :( ) and results are again differents.
OS | Core Utils | +1 day | +24 hours |
docker.io/bash:5.2.26-alpine3.19 | 9.4 | 2024-03-31T01:30:00.123+0000 | 2024-03-31T03:30:00.123+0200 |
VM Ubuntu 24.04 | 9.4 | 2024-03-31T04:30:00.123+0200 | 2024-03-31T03:30:00.123+0200 |

Debian 12.7 | 9.1 | 2024-03-31T04:30:00.123+0200 | 2024-03-31T03:30:00.123+0200 |
Git Bash | 8.32 | 2024-03-31T01:30:00.123+0000 | 2024-03-31T01:30:00.123+0000 |

Question 2: Is there something else than Core Utils which could have an effect on what the command date returns ?

The Winter daylight saving looks fine:

$ date -d "2023-10-28T03:30:00.123+0200 +1 days" "+%FT%T.%3N%z"
2023-10-29T02:30:00.123+0100
$ date -d "2023-10-28T03:30:00.123+0200 +24 hours" "+%FT%T.%3N%z"
2023-10-29T02:30:00.123+0100

$ date -d "2023-10-29T03:30:00.123+0100 -1 days" "+%FT%T.%3N%z"
2023-10-28T04:30:00.123+0200
$ date -d "2023-10-29T03:30:00.123+0100 -24 hours" "+%FT%T.%3N%z"
2023-10-28T04:30:00.123+0200

May, I misleading and I did'nt used the good format or others, let me know if it's the case.

Thanks in advance for your feedbacks.
Best Regards.

________________________________________________________________

Benjamin VARGIN

[Message part 2 (text/html, inline)]

Message #8 received at 73510 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Benjamin Vargin <benjamin.vargin.dev <at> proton.me>, 73510 <at> debbugs.gnu.org
Subject: Re: bug#73510: Questions on date command.
Date: Fri, 27 Sep 2024 13:55:39 +0100

On 27/09/2024 08:18, Benjamin Vargin via GNU coreutils Bug Reports wrote:
> Hello,
> 
> First of all, I would like to thank you for all the works accomplished by your teams !!
> 
> I'm currently implementing functions in bash which are using the command "date".
> I have noticed something strange when I realize manipulation during the daylight saving from Winter to Summer times in Europe.
> 
> Let me know, if it's the good place to submit my question or where I could do it.
> 
> In France, this year (2024), we have changed time during the night between the 30th and 31st of March.
> At 2.00 AM (31st march) -- it was --> 3.00 AM (31st march)
> 
> So if I do the date operation 30th march 2.30AM + 1 day, I'm expecting something like 31st march 3.30AM.
> 
> Observation using containers: bash - date (GNU coreutils) 9.5
> $ docker run --rm -it docker.io/bash:5.2.32
> $ apk update
> $ apk add --no-cache coreutils tzdata
> $ date --version
> date (GNU coreutils) 9.5
> $ export TZ="Europe/Paris"
> $ date -d "2024-03-30T02:30:00.123+0100 + 1 days" "+%FT%T.%3N%z"
> 2024-03-31T01:30:00.123+0100
> 
> $ date -d "2024-03-30T02:30:00.123+0100 + 24 hours" "+%FT%T.%3N%z"
> 2024-03-31T03:30:00.123+0200
> 
> # Minus looks fine
> $ date -d "2024-03-31T03:30:00.123+0200 - 1 days" "+%FT%T.%3N%z"
> 
> 2024-03-30T02:30:00.123+0100
> 
> $ date -d "2024-03-31T03:30:00.123+0200 - 24 hours" "+%FT%T.%3N%z"
> 2024-03-30T02:30:00.123+0100
> 
> The logic behind this is that the 31st is a day with 23 hours only, so 1 day was considered as 23 hours even if we didn't include all this day.
> $ date -d "2024-03-30T02:30:00.123+0100 + 23 hours" "+%FT%T.%3N%z"
> 2024-03-31T01:30:00.123+0100
> 
> This behavior could be understood when we are taking a more simple case (that's the current result):
> 2024-03-30T13:30:00.123+0100 + 1 day => 2024-03-30T14:30:00.123+0200
> But I understand less when we fall in the time shift window.
> 
> Question 1: Should 3.30AM be the good result to the operation "2024-03-30T02:30:00.123+0100 + 1 days" ?
> 
> In addition, I have tested on other virtual environments (sorry I don't have a native one :( ) and results are again differents.
> OS | Core Utils | +1 day | +24 hours |
> docker.io/bash:5.2.26-alpine3.19 | 9.4 | 2024-03-31T01:30:00.123+0000 | 2024-03-31T03:30:00.123+0200 |
> VM Ubuntu 24.04 | 9.4 | 2024-03-31T04:30:00.123+0200 | 2024-03-31T03:30:00.123+0200 |
> 
> Debian 12.7 | 9.1 | 2024-03-31T04:30:00.123+0200 | 2024-03-31T03:30:00.123+0200 |
> Git Bash | 8.32 | 2024-03-31T01:30:00.123+0000 | 2024-03-31T01:30:00.123+0000 |
> 
> Question 2: Is there something else than Core Utils which could have an effect on what the command date returns ?
> 
> The Winter daylight saving looks fine:
> 
> $ date -d "2023-10-28T03:30:00.123+0200 +1 days" "+%FT%T.%3N%z"
> 2023-10-29T02:30:00.123+0100
> $ date -d "2023-10-28T03:30:00.123+0200 +24 hours" "+%FT%T.%3N%z"
> 2023-10-29T02:30:00.123+0100
> 
> $ date -d "2023-10-29T03:30:00.123+0100 -1 days" "+%FT%T.%3N%z"
> 2023-10-28T04:30:00.123+0200
> $ date -d "2023-10-29T03:30:00.123+0100 -24 hours" "+%FT%T.%3N%z"
> 2023-10-28T04:30:00.123+0200
> 
> May, I misleading and I did'nt used the good format or others, let me know if it's the case.
> 
> Thanks in advance for your feedbacks.
> Best Regards.

This is a common gotcha which is discussed at:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

In summary currently one needs to anchor the relative adjustment
to it midpoint of the period being adjusted.
So for a +1 day adjustment, you would need to anchor to 12:00.

We may change things in future so the midpoint anchor is automatically chosen.

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.