Subject: bug#73510: Questions on date command.

From: Pádraig Brady <[email-masked]>
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