Dear Pádraig,
thank you for clarification! And for the pointer to the FAQ. With the assumption that the time
shifts all over the world will happen before noon, this will be a "working workaround".
And IMHO, this must be called a workaround and not a "have-to-known" , because it fixes
the current implementation to yield a result that will match the suggested semantic of input.
Do you know that I wasn't able to find this particular hint by using search engines; and not even
all by queries to the contemporary AI services? The later ones should search and know the content
of the internet much deeper than me :) But all the "best practices" to calculate the date
of yesterday mention this "pitfall" in any way.
Therefore I wonder how much "sophisticated" software will contain this issue.
Now sensitized, yesterday I discovered another example in our environment: The logging
tool of Apache httpd called rotatelogs is affected, also. Here, you may specify a
rotation interval in seconds - i guess the most used value is 84000 -- and this is based
on midnight.
We've mentioned previously about adding a flag to past_datetime2() to auto
select the mid point of the passed in relative quantity, but we've not gotten
around to that yet.
You may to decide to offer such a flag, but who will know ist, will use it, will change
existing software? I suggest the following "silent" change in implementation:
IF "a daylight save time situation is involved"
AND "the specified calculation don't explicit mention an hour" (i.e.
the evaluated argument calculate the time to midnight)
THEN use noon as the base time for calculating
To my opinion this approach is not a "breaking change" in general and therefore
will result in a very small number of false positives. But it will eliminate the
unrecognized (or already known, but unfixed) issue in a lot of existing and widely-used
software on next build.
with greetings
Guido
On 02.04.25 20:44, Pádraig Brady wrote:
On 02/04/2025 13:04, Jäkel, Guido wrote:
Dear Maintainers,
[...]
But I would expect that the semantic of "1 day ago" (or even "yesterday", which seems to be a defined
shortcut for this) will take care of this! And MUST deliver different results for "1 day ago" vs. "24 hours
ago" in such a case. For me, that's (one of) the reason to use an dedicated tool like "date" for an error-prone
calculation.
I am curious about your answer!
Currently "1 day ago" is just a synonym for "24 hours" ago.
This issue with relative adjustments around DST is mentioned in:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
where it suggests to specify a time like 12:00 to avoid DST transition times.
[...]
Padraig.
