Subject: RE: bug#14622: gdate

From: "Lien, John" <[email-masked]>
Date: Mon, 17 Jun 2013 13:02:25 +0000

Eric, it looks like "gdate" version is 6.4 and gnudate version is 1.16.

Regards,
John

d5lxfabappdev01z:/opt/auto/ gdate --version
date (GNU coreutils) 6.4
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

fabapps1:/opt/auto/ gnudate --version
date (GNU sh-utils) 1.16

-----Original Message-----
From: Eric Blake [mailto:[email-masked]] 
Sent: Saturday, June 15, 2013 5:08 AM
To: Lien, John
Cc: [email-masked]
Subject: Re: bug#14622: gdate

tag 14622 moreinfo
thanks

On 06/14/2013 10:22 PM, Lien, John wrote:
> I tried following X86 version of "gdate", and it received different result as the 'gnudate", can you explain the difference? It seems that "gnudate: is correct.
> 
> Following "gdate" is running Solaris 5.10 on X86 UNIX host; "gnudate" is running on Solaris 5.8 on Sun-Fire_V240.
> 
> /usr/local/bin/gdate --date '20130614 14:46:43 + 1 sec' '+%y%m%d:%H%M%S'
> 130614:094544
> 
> /usr/local/bin/gnudate --date '20130614 14:46:43 + 1 sec' '+%y%m%d:%H%M%S'
> 130614:144644

Most likely, the difference lies in the version of coreutils that you
are using.  Please also tell use 'gdate --version' and 'gnudate
--version'.  And remember that we have improved the parser over time, so
it may be that your gdate binary is from an older build that had a bug
fixed in the version compiled into your gnudate binary.  For example,
this NEWS entry for coreutils 6.9.90 looks like it might be relevant:

  date -d now accepts strings of the form e.g., 'YYYYMMDD +N days',
  in addition to the usual 'YYYYMMDD N days'.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org