"Sergey Poznyakoff" <g...@gnu.org.ua> 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
