On 02/04/2025 13:04, Jäkel, Guido wrote:
Dear Maintainers,I want to ask what's the exact semantic semantic and functionality of the keyword "1 day ago" and "yesterday" in parse-datetime2(), which is used by the `date`-command of coreutils. Because in a batch job running at every midnight (at 00:00), on 2025-03-31 the line YESTERDATE=`date -d "1 day ago" +%Y%m%d` in a bash script returns `20250329` instead the expected `20250330`! Note that this is happens at timezone `Europe/Berlin`, 2025-03-30 was the day of switching to summertime and this day counts 23 hours. From that, I guess that "1 day ago" is implemented as an equivalent of "24 hours ago" and at (2025-03-31 00:00) - 24h the corresponding timestamp was (2025-03-29 23:00). 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! Background: This script is used to prepare a typical "rename open logfile rolling before signaling HUP to the daemon".
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. 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. Padraig.
