Re: parse-datetime2: Semantic and implementation of "1 day ago"
> Maybe the solution isn't to flip-flop the implementation here, but to > document this concern and some method to disambiguate how to reliably > get the intended semantics. FWIW, parse_datetime prints a warning if DST changes after date adjustment[1,2]. Unfortunately, only in debugging mode, so most of the time it goes unnoticed. The comment refers to https://bugs.gnu.org/8357, which may give a good starting point for documenting this. Regards, Sergey [1] https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/parse-datetime.y#n2190 [2] https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/parse-datetime.y#n2315
Re: parse-datetime2: Semantic and implementation of "1 day ago"
"Sergey Poznyakoff" writes: >> Maybe the solution isn't to flip-flop the implementation here, but to >> document this concern and some method to disambiguate how to reliably >> get the intended semantics. > > FWIW, parse_datetime prints a warning if DST changes after date > adjustment[1,2]. Unfortunately, only in debugging mode, so most of the time > it goes unnoticed. The comment refers to https://bugs.gnu.org/8357, > which may give a good starting point for documenting this. Right -- and the current behaviour is already well documented: The unit of time displacement may be selected by the string ‘year’ or ‘month’ for moving by whole years or months. These are fuzzy units, as years and months are not all of equal duration. More precise units are ‘fortnight’ which is worth 14 days, ‘week’ worth 7 days, ‘day’ worth 24 hours, ‘hour’ worth 60 minutes, ‘minute’ or ‘min’ worth 60 seconds, and ‘second’ or ‘sec’ worth one second. An ‘s’ suffix on these units is accepted and ignored. And also the recommendation to use UTC in these situations: Also, take care when manipulating dates around clock changes such as daylight saving leaps. In a few cases these have added or subtracted as much as 24 hours from the clock, so it is often wise to adopt universal time by setting the ‘TZ’ environment variable to ‘UTC0’ before embarking on calendrical calculations. It seems fine to introduce new terms for the semantics requested here, but I think it would be a bad idea to change '1 day ago' to not be identical to '24 hours' anymore. That is long-standing documented behaviour, and it is one reasonable interpretation out of several possible interpretations. /Simon signature.asc Description: PGP signature
Re: parse-datetime2: Semantic and implementation of "1 day ago"
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
Re: parse-datetime2: Semantic and implementation of "1 day ago"
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
Re: parse-datetime2: Semantic and implementation of "1 day ago"
... and that's exactly the point! Both are "right" in their context. But *here* there already *is* the (varying) possibility to exactly express what you mean in you domain specific context. The available syntax allow to specify (as an example) "24 hours" and also "1 day" (what might be 23 hours), or " days" vs "1 week" or much more evident "?? days" vs. "1 month" (what most will treat as "the same weekday with four week distance"). Not tested, but it seems that even things like "last Friday of month" are implemented. +1 It's domain specific. In a Gantt chart application, for example, "1 day ago" most certainly means "same time as now only yesterday"; but that's because Gantt charts are used to schedule human work, and human work is most often aligned to the time-in-the-day (influenced by the time zone). Whereas in an astronomical application, "1 day ago" most certainly means "24 hours ago". Bruno On 03.04.25 11:15, Bruno Haible wrote: Simon Josefsson wrote: To give a different point of view, I'm not sure your suggested semantic here is the only reasonable interpretation. The semantic you seem to want is "same time as now only yesterday". However you ask for "1 day ago". I think it is not unreasonable to interprete "1 day ago" to mean "24 hours ago".
Re: parse-datetime2: Semantic and implementation of "1 day ago"
Simon Josefsson wrote: > To give a different point of view, I'm not sure your suggested semantic > here is the only reasonable interpretation. The semantic you seem to > want is "same time as now only yesterday". However you ask for "1 day > ago". I think it is not unreasonable to interprete "1 day ago" to mean > "24 hours ago". +1 It's domain specific. In a Gantt chart application, for example, "1 day ago" most certainly means "same time as now only yesterday"; but that's because Gantt charts are used to schedule human work, and human work is most often aligned to the time-in-the-day (influenced by the time zone). Whereas in an astronomical application, "1 day ago" most certainly means "24 hours ago". Bruno
Re: parse-datetime2: Semantic and implementation of "1 day ago"
Guido Jäkel writes: > 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. To give a different point of view, I'm not sure your suggested semantic here is the only reasonable interpretation. The semantic you seem to want is "same time as now only yesterday". However you ask for "1 day ago". I think it is not unreasonable to interprete "1 day ago" to mean "24 hours ago". https://en.wikipedia.org/wiki/Day If we change "1 day ago" to take into account daylight savings changes and make adjustment, I suspect we will get reports that complain that "1 day ago" sometimes mean 23 or 25 hours instead of always 24 hours. I think that would be a valid complaint too. Maybe the solution isn't to flip-flop the implementation here, but to document this concern and some method to disambiguate how to reliably get the intended semantics. For some applications, "1 day" can be defined as 86400 seconds just like SI. For some applications, "1 day" can be defined to mean 86400 seconds except when DST occured where it can be 23 or 25 hours instead. For some applications, "1 day" can probably mean something entirely different too (24 hours 40 minute Mars days anyone?). /Simon signature.asc Description: PGP signature
Re: parse-datetime2: Semantic and implementation of "1 day ago"
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.
Re: parse-datetime2: Semantic and implementation of "1 day ago"
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.
