bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#73510: Questions on date command.


From: Pádraig Brady
Subject: bug#73510: Questions on date command.
Date: Fri, 27 Sep 2024 13:55:39 +0100
User-agent: Mozilla Thunderbird Beta

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]