GNU bug report logs -
#73510
Questions on date command.
Previous Next
Full log
View this message in rfc822 format
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
This bug report was last modified 125 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.