On 03.04.25 13:46, Pádraig Brady wrote:
On 03/04/2025 06:36, Guido Jäkel wrote:
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.
Well it is a breaking change at the API level, which is why I suggested the
flag in the API.
I was thinking GNU coreutils date would auto set the flag though.
Then if the input and output resolution are >= the relative quantity,
we'd auto select the midpoint as the basis of the adjustment.
cheers,
Pádraig
Well,
thank you for discussion. I'll leave this to your domain for now. I hope this
will trigger things in a way that I don't see this issue next year, again. To
archive this goal, the change must be propagated into the used software
components running in production then.
Thank you for support in advance
Guido
