bug#14622: gdate

[Lien, John]

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:address@hidden 
Sent: Saturday, June 15, 2013 5:08 AM
To: Lien, John
Cc: address@hidden
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