bug#26101: Counterproductive calculation order in date

[Ulf Zibis]

Am 15.03.2017 um 15:40 schrieb Assaf Gordon:
> To give more details about the inter working of date adjustments:
Much thanks for outlining these details in great clarity.

> You'd like to be able to do date calculations in some predictable way,
Yes!
Currently the result is not predictable because the order of processing 
the terms is not defined transparently.

> in your case to be able to change a file's timestamp.

Not any more as thanks to Eric I now know how to do that by only help of 
touch.

> However,
> consider that adjusting by any scale (years/months/days/hours/minutes) will
> have side-effects.
>
> Adjusting by months can shift days (e.g. "2016-03-30 - 1 month" is still march).
> Adjusting by days can shift hours (e.g. on Day light saving time),
> Adjusting by hours can stay in the same day (e.g. "+24 hours" on a when day light saving 
> results in 25 "hours").
> etc.
>
> It is the edge-cases that make day adjustment tricky (e.g. "+1 month" is not "+30 days", "+1 
> day" is not always "+24 hours", etc.).
>
> If you can come up with reliable and predictable rules for date adjustment that 
> will not have these unexpected results - there's definitely room for 
> improvements.

I do not see any problems with adjustment when determining the 
processing order from left to right, but I'm not a real specialist to 
that subject.

> However, there's also the existing behavior and backwards compatibility that 
> will need to be taken into account.

This may be an important issue.
On the other hand, such side effects could also result from arbitrary 
code changes, as the processing order to follow is nowhere determined.
Maybe an intelligent search over all shell scripts of a typical Linux 
installation could discover the usage of such cases.

-Ulf

smime.p7s
Description: S/MIME Cryptographic Signature