GNU bug report logs - #22397
Date -- Format arithemtic yields unexpected results

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22397 in the body.
You can then email your comments to 22397 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Adam Danischewski <adam.danischewski <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Date -- Format arithemtic yields unexpected results
Date: Sun, 17 Jan 2016 22:53:59 -0500

[Message part 1 (text/plain, inline)]

$> date
Sun Jan 17 22:49:40 EST 2016
$> date -d"04:00"
Sun Jan 17 04:00:00 EST 2016
$> date -d"04:00 +1 day"
Sun Jan 17 22:00:00 EST 2016

To fix this, a work around for me now is:
$> date -d"$(date -d"04:00") +1 day"
Mon Jan 18 04:00:00 EST 2016

+AMD

[Message part 2 (text/html, inline)]

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Adam Danischewski <adam.danischewski <at> gmail.com>, 22397 <at> debbugs.gnu.org
Subject: Re: bug#22397: Date -- Format arithemtic yields unexpected results
Date: Mon, 18 Jan 2016 14:16:05 +0000

tag 22397 notabug
close

On 18/01/16 03:53, Adam Danischewski wrote:
> $> date
> Sun Jan 17 22:49:40 EST 2016
> $> date -d"04:00"
> Sun Jan 17 04:00:00 EST 2016
> $> date -d"04:00 +1 day"
> Sun Jan 17 22:00:00 EST 2016
> 
> To fix this, a work around for me now is:
> $> date -d"$(date -d"04:00") +1 day"
> Mon Jan 18 04:00:00 EST 2016

The +1 is taken as a timezone offset.
You'll want:

date -d '04:00 today +1 day'

Note also the relative date discussion at:
http://bugs.gnu.org/18159

cheers,
Pádraig.

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

From: Adam Danischewski <adam.danischewski <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 22397 <at> debbugs.gnu.org
Subject: Re: bug#22397: Date -- Format arithemtic yields unexpected results
Date: Tue, 19 Jan 2016 11:19:48 -0500

[Message part 1 (text/plain, inline)]

On my system '04:00 doesn't change the timezone string if it is changing
the timezone:

$> date -d '04:00'
Tue Jan 19 04:00:00 EST 2016
$> date -d '04:00 today +1 day'
Tue Jan 19 22:00:00 EST 2016
$> date -d '04:00 +1 day'
Tue Jan 19 22:00:00 EST 2016


Also I noticed the format of the Timezone doesn't shift for RFC-2822
 zone = (( "+" / "-" ) 4DIGIT) / obs-zone

   The zone specifies the offset from Coordinated Universal Time (UTC,
   formerly referred to as "Greenwich Mean Time") that the date and
   time-of-day represent.  The "+" or "-" indicates whether the
   time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
   Universal Time.  The first two digits indicate the number of hours
   difference from Universal Time, and the last two digits indicate the
   number of minutes difference from Universal Time.  (Hence, +hhmm
   means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
   minutes).  The form "+0000" SHOULD be used to indicate a time zone at
   Universal Time.  Though "-0000" also indicates Universal Time, it is
   used to indicate that the time was generated on a system that may be
   in a local time zone other than Universal Time and therefore
   indicates that the date-time contains no information about the local
   time zone.

$> date -R
Tue, 19 Jan 2016 10:58:01 -0500

$> date -R -d'04:00 +1'
Mon, 18 Jan 2016 22:00:00 -0500

Also is it documented that +[0-9] does a timezone shift? On the man page, I
saw it stipulate using the environment variable TZ and in the info page
it states:

 The time may alternatively be followed by a time zone correction,
  expressed as `SHHMM', where S is `+' or `-', HH is a number of zone
  hours and MM is a number of zone minutes.  The zone minutes term, MM,
  may be omitted, in which case the one- or two-digit correction is
  interpreted as a number of hours.  You can also separate HH from MM
  with a colon.  When a time zone correction is given this way, it forces
  interpretation of the time relative to Coordinated Universal Time
  (UTC), overriding any previous specification for the time zone or the
  local time zone.  For example, `+0530' and `+05:30' both stand for the
  time zone 5.5 hours ahead of UTC (e.g., India).  This is the best way to
  specify a time zone correction by fractional parts of an hour.  The
  maximum zone correction is 24 hours.

It seems wrong to accept less than a 4 digit TZ correction
according to the info page. Especially since the +1 is followed
by day. I think the logic for this should probably be that if
you are going to be friendly and presume that +1 is a shorthand
timezone shift that you should do so after you have parsed the
date string for more expected syntaxes.


On Mon, Jan 18, 2016 at 9:16 AM, Pádraig Brady <P <at> draigbrady.com> wrote:

> tag 22397 notabug
> close
>
> On 18/01/16 03:53, Adam Danischewski wrote:
> > $> date
> > Sun Jan 17 22:49:40 EST 2016
> > $> date -d"04:00"
> > Sun Jan 17 04:00:00 EST 2016
> > $> date -d"04:00 +1 day"
> > Sun Jan 17 22:00:00 EST 2016
> >
> > To fix this, a work around for me now is:
> > $> date -d"$(date -d"04:00") +1 day"
> > Mon Jan 18 04:00:00 EST 2016
>
> The +1 is taken as a timezone offset.
> You'll want:
>
> date -d '04:00 today +1 day'
>
> Note also the relative date discussion at:
> http://bugs.gnu.org/18159
>
> cheers,
> Pádraig.
>

[Message part 2 (text/html, inline)]

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 22397 <at> debbugs.gnu.org
Subject: Re: bug#22397: Date -- Format arithemtic yields unexpected results
Date: Wed, 24 Oct 2018 15:42:25 -0600

tags 22397 notabug
close 22397
stop

(triaging old bugs)

On 18/01/16 07:16 AM, Pádraig Brady wrote:
> 
> On 18/01/16 03:53, Adam Danischewski wrote:
>> $> date
>> Sun Jan 17 22:49:40 EST 2016
>> $> date -d"04:00"
>> Sun Jan 17 04:00:00 EST 2016
>> $> date -d"04:00 +1 day"
>> Sun Jan 17 22:00:00 EST 2016
>>
>> To fix this, a work around for me now is:
>> $> date -d"$(date -d"04:00") +1 day"
>> Mon Jan 18 04:00:00 EST 2016
> 
> The +1 is taken as a timezone offset.
> You'll want:
> 
> date -d '04:00 today +1 day'
> 
> Note also the relative date discussion at:
> http://bugs.gnu.org/18159

date now supports the "--debug" option
to make such troubleshooting easier.

With no further comments in over a year,
I'm closing this bug.

-assaf

Previous Next

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