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

Previous Next

Package: coreutils;

Reported by: Benjamin Vargin <benjamin.vargin.dev <at> proton.me>

Date: Fri, 27 Sep 2024 07:39:01 UTC

Severity: wishlist

Full log


View this message in rfc822 format

From: Benjamin Vargin <benjamin.vargin.dev <at> proton.me>
To: 73510 <at> debbugs.gnu.org
Subject: bug#73510: 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)]

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.