GNU bug report logs - #26101
Counterproductive calculation order in date

Previous Next

Package: coreutils;

Reported by: Ulf Zibis <Ulf.Zibis <at> gmx.de>

Date: Wed, 15 Mar 2017 00:42:01 UTC

Severity: normal

Tags: notabug

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #35 received at 26101 <at> debbugs.gnu.org (full text, mbox):

From: Ulf Zibis <Ulf.Zibis <at> gmx.de>
To: Assaf Gordon <assafgordon <at> gmail.com>, 26101 <at> debbugs.gnu.org
Subject: Re: bug#26101: Counterproductive calculation order in date
Date: Wed, 15 Mar 2017 23:37:59 +0100
[Message part 1 (text/plain, inline)]
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 (application/pkcs7-signature, attachment)]

This bug report was last modified 6 years and 265 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.