bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[C de-Avillez]

On Tue, Apr 16, 2019 at 1:37 PM Assaf Gordon  wrote:

> Thank you both for testing.
>
> So, to summarize:
> whenever "inv-year" fails - it is a problem with glibc on your
> setup, *not* a problem in coreutils' date(1) program.
>
> If there is a setup where "inv-year" succeeds but date(1) still fails,
> then it is a problem in coreutils.
>
> I'm glad to hear latest Ubuntu 19.04 is working fine
> (though the reason for the earlier failure is still a mystery).
>
> As Paul suggested, trying 'strace' on the failing system
> might reveal more details.

Will run strace again. Meanwhile, I decided to test time zones. My
default TZ is America/Chicago -- in my laptop date fails. I then moved
to TZ=UTC, and it worked:

cerdea@piatam:~/Downloads$ echo $TZ
America/Chicago
cerdea@piatam:~/Downloads$ date
Tue Apr 16 10:04:48 CDT 2019

130 cerdea@piatam:~/Downloads$ date --debug +%-Y -d '- 110 years'
date: parsed relative part: -110 year(s)
date: input timezone: TZ="America/Chicago" environment value
date: using current time as starting value: '10:05:01'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 10:05:01'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: error: adding relative date resulted in an invalid date:
'(Y-M-D) 1909-04-16 10:05:01'
date: invalid date ‘- 110 years’

1 cerdea@piatam:~/Downloads$ export TZ=UTC
cerdea@piatam:~/Downloads$ date --debug +%-Y -d '- 110 years'
date: parsed relative part: -110 year(s)
date: input timezone: TZ="UTC" environment value
date: using current time as starting value: '15:05:21'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 15:05:21'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: after date adjustment (-110 years, +0 months, +0 days),
date: new date/time = '(Y-M-D) 1909-04-16 15:05:21'
date: '(Y-M-D) 1909-04-16 15:05:21' = -1915865679 epoch-seconds
date: timezone: TZ="UTC" environment value
date: final: -1915865679.603138125 (epoch-seconds)
date: final: (Y-M-D) 1909-04-16 15:05:21 (UTC)
date: final: (Y-M-D) 1909-04-16 15:05:21 (UTC+00)
1909

Will keep on trying.
-- 
..hggdh..

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[Assaf Gordon]

Hello,

On 2019-04-15 5:10 p.m., O. Emmerson wrote:

For me it gives:

$ ./inv-year
time() = 1555369320
localtime() = 2019-04-16 00:02:00
   (mday=16 wday=2, isdst=1)
struct tm (after adjustment) = 0009-04-16 00:02:00
   (mday=16 wday=2, isdst=1)
inv-year: mktime() failed: Value too large for defined data type

>

On 2019-04-15 6:50 p.m., C de-Avillez wrote:
[...]

root@u1904:~# gcc -o inv-year inv-year.c
root@u1904:~# ./inv-year
time() = 1555375408
localtime() = 2019-04-16 00:43:28
   (mday=16 wday=2, isdst=0)
struct tm (after adjustment) = 0009-04-16 00:43:28
(mday=16 wday=2, isdst=0)
mktime() after date adjustment = -61874061392

So: a pristine 19.04 runs it. My laptop (which is my work machine,
full of other packages & programs), does not.



Thank you both for testing.

So, to summarize:
whenever "inv-year" fails - it is a problem with glibc on your
setup, *not* a problem in coreutils' date(1) program.

If there is a setup where "inv-year" succeeds but date(1) still fails,
then it is a problem in coreutils.

I'm glad to hear latest Ubuntu 19.04 is working fine
(though the reason for the earlier failure is still a mystery).

As Paul suggested, trying 'strace' on the failing system
might reveal more details.

regards,
 - assaf

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[C de-Avillez]

It has to be something messing/interacting with coreutils/date on
19.04 (and probably on Tumbleweed).

I created a new container with 19.04, and then:
* apt build-dep coreutils
* apt install rsync wget git
* git clone git://git.sv.gnu.org/coreutils
* cd coreutils
* export FORCE_UNSAFE_CONFIGURE=1 # too lazy to adduser
* ./boostrap
* ./configure
* make

at the end of the build I ran both the provided date and the
just-built one. Both ran correctly:

root@u1904:~/coreutils# date --debug +%-Y -d '- 2010 years'
date: parsed relative part: -2010 year(s)
date: input timezone: system default
date: using current time as starting value: '00:30:39'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 00:30:39'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: after date adjustment (-2010 years, +0 months, +0 days),
date: new date/time = '(Y-M-D) 0009-04-16 00:30:39'
date: '(Y-M-D) 0009-04-16 00:30:39' = -61874062161 epoch-seconds
date: timezone: system default
date: final: -61874062161.081576777 (epoch-seconds)
date: final: (Y-M-D) 0009-04-16 00:30:39 (UTC)
date: final: (Y-M-D) 0009-04-16 00:30:39 (UTC+00)
9

root@u1904:~/coreutils# src/date --debug +%-Y -d '- 2010 years'
date: parsed relative part: -2010 year(s)
date: input timezone: system default
date: using current time as starting value: '00:30:49'
date: using current date as starting value: '(Y-M-D) 2019-04-16'
date: starting date/time: '(Y-M-D) 2019-04-16 00:30:49'
date: warning: when adding relative months/years, it is recommended to
specify the 15th of the months
date: after date adjustment (-2010 years, +0 months, +0 days),
date: new date/time = '(Y-M-D) 0009-04-16 00:30:49'
date: '(Y-M-D) 0009-04-16 00:30:49' = -61874062151 epoch-seconds
date: timezone: system default
date: final: -61874062151.239637280 (epoch-seconds)
date: final: (Y-M-D) 0009-04-16 00:30:49 (UTC)
date: final: (Y-M-D) 0009-04-16 00:30:49 (UTC+00)
9

I then compiled & ran Asaf's inv-year.c:

root@u1904:~# gcc -o inv-year inv-year.c
root@u1904:~# ./inv-year
time() = 1555375408
localtime() = 2019-04-16 00:43:28
  (mday=16 wday=2, isdst=0)
struct tm (after adjustment) = 0009-04-16 00:43:28
   (mday=16 wday=2, isdst=0)
mktime() after date adjustment = -61874061392

So: a pristine 19.04 runs it. My laptop (which is my work machine,
full of other packages & programs), does not.

Oh -- Assaf, yes, I am very well aware 19.04 has not yet been
released. But -- unless we find something critical -- it is basically
what will be  released in a few days. I do not expect a rebuild of the
coreutils package, for example.

Cheers,

..C..

On Mon, Apr 15, 2019 at 6:11 PM O. Emmerson  wrote:
>
> On 15/04/2019 21:55, Assaf Gordon wrote:
> > To see if this is glibc issue, or perhaps an gnulib/mktime_z wrapper
> > issue, can you (and/or others) try the attached C program?
> >
> > It calls time(2)+localtime(3)+mktime(3) to emulate the date adjustment.
> >
> > Because the adjustment is to year 9 (about 1961 years before epoch),
> > the time_t value is negative. perhaps that's the issue? or perhaps
> > combined with a specific timezone it becomes problematic?
>
> For me it gives:
>
> $ ./inv-year
> time() = 1555369320
> localtime() = 2019-04-16 00:02:00
>(mday=16 wday=2, isdst=1)
> struct tm (after adjustment) = 0009-04-16 00:02:00
> (mday=16 wday=2, isdst=1)
> inv-year: mktime() failed: Value too large for defined data type
>
>
> And debug gives:
>
> $ date +%-Y -d "- 112 years" --debug
> date: parsed relative part: -112 year(s)
> date: input timezone: system default
> date: using current time as starting value: '00:04:32'
> date: using current date as starting value: '(Y-M-D) 2019-04-16'
> date: starting date/time: '(Y-M-D) 2019-04-16 00:04:32'
> date: warning: when adding relative months/years, it is recommended to
> specify the 15th of the months
> date: error: adding relative date resulted in an invalid date: '(Y-M-D)
> 1907-04-16 00:04:32'
> date: invalid date ‘- 112 years’
>
>
>
>
>


-- 
..hggdh..

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[C de-Avillez]

cerdea@piatam:~/Downloads$ gcc -o inv-year inv-year.c
cerdea@piatam:~/Downloads$ ./inv-year
time() = 1555368087
localtime() = 2019-04-15 17:41:27
 (mday=15 wday=1, isdst=1)
struct tm (after adjustment) = 0009-04-15 17:41:27
  (mday=15 wday=1, isdst=1)
inv-year: mktime() failed: Value too large for defined data type
1 cerdea@piatam:~/Downloads$

On Mon, Apr 15, 2019 at 3:55 PM Assaf Gordon  wrote:
>
> Thanks Bernhard,
>
> On 2019-04-15 2:14 p.m., Bernhard Voelker wrote:
> > I can easily reproduce here on my regular openSUSE:Tumbleweed from latest 
> > git:
> >
> >$ src/date --debug '+%-Y' -d '- 2010 years'
> []
> >date: error: adding relative date resulted in an invalid date: '(Y-M-D) 
> > 0009-04-15 22:10:37'
>
> This makes it easy to pinpoint (hooray for "--debug" :) ).
>
> This error is given if gnulib's "mktime_z" fails
> to convert the adjusted "struct tm" to "time_t"
> (adjusted because its tm_year was decremented by 2010).
>
> https://opengrok.housegordon.com/source/xref/gnulib/lib/parse-datetime.y#2177
>
> To see if this is glibc issue, or perhaps an gnulib/mktime_z wrapper
> issue, can you (and/or others) try the attached C program?
>
> It calls time(2)+localtime(3)+mktime(3) to emulate the date adjustment.
>
> Because the adjustment is to year 9 (about 1961 years before epoch),
> the time_t value is negative. perhaps that's the issue? or perhaps
> combined with a specific timezone it becomes problematic?
>
> On my system it gives:
> 
>$ gcc -o inv-year inv-year.c
>
>$ ./inv-year
>time() = 1555361050
>localtime() = 2019-04-15 14:44:10
>  (mday=15 wday=1, isdst=1)
>struct tm (after adjustment) = 0009-04-15 14:44:10
>   (mday=15 wday=1, isdst=1)
>mktime() after date adjustment = -61874070118
> 
>
>
> regards,
>   - assaf
>
>
>
>
>
>


-- 
..hggdh..

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[Bernhard Voelker]

On 4/15/19 9:41 PM, Assaf Gordon wrote:
> A good starting point is adding the "--debug" option to date(1)
> and examining its output.

Hi Assaf,

I can easily reproduce here on my regular openSUSE:Tumbleweed from latest git:

  $ src/date --debug '+%-Y' -d '- 2010 years'
  date: parsed relative part: -2010 year(s)
  date: input timezone: system default
  date: using current time as starting value: '22:10:37'
  date: using current date as starting value: '(Y-M-D) 2019-04-15'
  date: starting date/time: '(Y-M-D) 2019-04-15 22:10:37'
  date: error: adding relative date resulted in an invalid date: '(Y-M-D) 
0009-04-15 22:10:37'
  src/date: invalid date '- 2010 years'

Have a nice day,
Berny

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[Assaf Gordon]

Hello,

On 2019-04-15 11:55 a.m., C de-Avillez wrote:

19.04:


It is worth noting that Ubuntu 19.04 has not been officially released
yet, so you are testing on a development branch (or a release-candidate,
or a special built infrastructure as hinted by your path).


cerdea@piatam:/data/buildd/coreutils$ date +%-Y -d '- 2010 years'
date: invalid date ‘- 2010 years’
1 cerdea@piatam:/data/buildd/coreutils$ date --version
date (GNU coreutils) 8.30


[...]


On Mon, Apr 15, 2019 at 12:16 PM O. Emmerson  wrote:


$ file /bin/date
/bin/date: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=26fa7f6c43c354d8c5647ebf946255a2b8e3c53d,
stripped


I just downloaded a recent daily snapshot of
ubuntu desktop live CD for amd64 from 
http://cdimage.ubuntu.com/daily-live/current/ .

The file "disco-desktop-amd64.iso" dated 2019-04-13 22:28 size 1.9GB,
with the following checksum:

  $ sha1sum disco-desktop-amd64.iso
  b89fb143b51e17482a3882abe2f5f4e3b69942fe  disco-desktop-amd64.iso

Booting with QEMU as live-cd, I tested the same command and got "9" as
the (correct) result. So this can't be easily reproduced.

An interesting benefit of reproducible builds is that I see on the
live-cd image the sha1 checksum of "/bin/date" is the same as you listed
above. This hints to me the problem is somewhere else in your setup.

As this is not an official release, we really can't support it.
You'll have to dig further and see what is the issue.

A good starting point is adding the "--debug" option to date(1)
and examining its output.

regards,
 - assaf

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[C de-Avillez]

I have ran a few tests on Ubuntu 16.04, 18.04, 18.10, and 19.04 (all X86_64):

16.04:

root@u1604:~# date +%-Y -d '- 2010 years'
9
root@u1604:~# date --version
date (GNU coreutils) 8.25
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

18.04:

root@bionic:~# date +%-Y -d '- 2010 years'
9
root@bionic:~# date --version
date (GNU coreutils) 8.28
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

18.10:

root@u1810:~# date +%-Y -d '- 2010 years'
9
root@u1810:~# date --version
date (GNU coreutils) 8.28
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

19.04:

cerdea@piatam:/data/buildd/coreutils$ date +%-Y -d '- 2010 years'
date: invalid date ‘- 2010 years’
1 cerdea@piatam:/data/buildd/coreutils$ date --version
date (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

Interestingly, it is also failing on git head:

130 cerdea@piatam:/data/buildd/coreutils$ src/date +%-Y -d '- 2010 years'
src/date: invalid date ‘- 2010 years’
1 cerdea@piatam:/data/buildd/coreutils$ src/date --version
date (GNU coreutils) 8.31.12-6d78a
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David MacKenzie.

On Mon, Apr 15, 2019 at 12:16 PM O. Emmerson  wrote:
>
> $ file /bin/date
> /bin/date: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
> GNU/Linux 3.2.0, BuildID[sha1]=26fa7f6c43c354d8c5647ebf946255a2b8e3c53d,
> stripped
>
>
>
>


-- 
..hggdh..

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[O. Emmerson]

$ file /bin/date
/bin/date: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=26fa7f6c43c354d8c5647ebf946255a2b8e3c53d,
stripped

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[O. Emmerson]

I have downloaded and compiled 8.31 from source to see if it makes any
difference and have gotten the same error.

bug#35289: closed (Re: bug#35289: date+%-Y -d "- N years" errors when N > 111)

[O. Emmerson]

On 15/04/2019 17:02, GNU bug Tracking System wrote:

It works for me with coreutils 8.31 on RHEL 7 x86-64:

$ date +%-Y -d "- 2010 years"
9

Most likely you are running on a 32-bit machine, and dates in the year 9
cannot be represented in a 32-bit timestamp. So a simple fix would be
for you to switch to a 64-bit machine.


I am running a 64bit version of Ubuntu.
Anyway, as I said, I have been running this command successfully for
years until now.

Here is the full system info from reportbug copied from by original bug
on Ubuntu's tracker:

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: coreutils 8.30-1ubuntu1
ProcVersionSignature: Ubuntu 5.0.0-11.12-generic 5.0.6
Uname: Linux 5.0.0-11-generic x86_64
ApportVersion: 2.20.10-0ubuntu27
Architecture: amd64
Date: Sun Apr 14 10:59:36 2019
InstallationDate: Installed on 2017-10-08 (553 days ago)
InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64
(20170215.2)
SourcePackage: coreutils
UpgradeStatus: Upgraded to disco on 2019-04-13 (1 days ago)

bug#26081: closed (Re: bug#26081: --date=STRING error that started midnight 3/12)

[Fevzi Karavelioglu]

It is a great FAQ and yes I see it covers this.  Now I understand it 
would not be able to tell me the 2AM for the day we are skipping it. 
What threw me off was also the fact that 'tomorrow' was a day we did not 
skip 2AM.  So the clocks went forward at 2AM on 3/12. But I was asking 
for the next day 2AM. So it was still failing because the 2AM was 
skipped on the previous day, correct?


And yes it is working fine today.

Luckily my application is not mission critical.  But I still need to 
figure out a way to avoid this problem in the future (unless we do away 
with DST real soon, can't happen too soon for me!). I will need to add 
special logic to my code to handle this. It is going to be fun.


Fevzi

On 3/13/17 5:18 AM, GNU bug Tracking System wrote:

Your bug report

#26081: --date=STRING error that started midnight 3/12

which was filed against the coreutils package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 26...@debbugs.gnu.org.

bug#17253: Re: bug#17253: date --date=-x\ days

[Bob Proulx]

hanes wrote:
 You got me to the right point with the daylight saving time.

All of us were pretty sure that would be the root of the problem.

 I really do not thought it is that trivial.
 So I am sorry to bother You with this, and disgrace me like that.

Please do not worry.  We are happy to help.

 But to answer the Questions:
 I switched my bios clock two hours forward, but of course it had no
 effect; so everything is actually still all right.

You are using a Unix-like system and should be running one of the NTP
daemons to keep your clock adjusted correctly.  I don't know about
Ubuntu but most systems will run an ntp daemon to do this.  If you
do, I think you are, then your BIOS setting will not matter because as
soon as the operating system boots it will set the clock to the
correct time from the Internet time servers.

When you say BIOS you really mean the hardware clock.  The hardware
clock is the initial time setting when there isn't any other time
source.  Such as when booting a system without an Internet connection.
In the case of not having an Internet connection then the hardware
clock setting is the best setting available.  But in the case of a
network connection to the Internet time servers then that time will
override the hardware clock time.

So as you can see in a network environment changing the clock from the
BIOS settings will not have any effect!

 My timezone switched in that period to summertime, here is the output:
 user@host - Current Time: 07:42   :~$
 date -d 12:00 today -346 hours +Output: %Y.%m.%d__%H  Timezone: %z
 Output: 2014.03.30__01  Timezone: +0100
 user@host - Current Time: 07:42   :~$
 date -d 12:00 today -345 hours +Output: %Y.%m.%d__%H  Timezone: %z
 Output: 2014.03.30__03  Timezone: +0200

Yes.  If you work with UTC time then you can avoid all of those DST
problems.  But working at 12:00 noon avoids the problem too because no
known timezone changes DST in the middle of the day.

 So, have a nice Day anyway.
 with kind regards,

You too.  I am marking this bug as closed with this message.

Bob

bug#17253: Re: bug#17253: date --date=-x\ days

[hanes]

You got me to the right point with the daylight saving time.
I really do not thought it is that trivial.
So I am sorry to bother You with this, and disgrace me like that.

But to answer the Questions:
I switched my bios clock two hours forward, but of course it had no
effect; so everything is actually still all right.

My timezone switched in that period to summertime, here is the output:
user@host - Current Time: 07:42   :~$
date -d 12:00 today -346 hours +Output: %Y.%m.%d__%H  Timezone: %z
Output: 2014.03.30__01  Timezone: +0100
user@host - Current Time: 07:42   :~$
date -d 12:00 today -345 hours +Output: %Y.%m.%d__%H  Timezone: %z
Output: 2014.03.30__03  Timezone: +0200

So, have a nice Day anyway.

with kind regards,

hanes

Re: bug about date

[Philip Rowlands]

On Mon, 8 Mar 2010, gaosh wrote:


I use the command: date +%Y%m%d%H -d 1990-04-13 12 36 hours
But I get the result: 1990041501 ! The correct one should be 1990041500.


The result depends on your system's local timezone, which I assume is 
set to Asia/Shanghai or equivalent Chinese location. 1990-04-14 was a 
day when daylight saving time began, so you're seeing the extra hour 
gained. This is more obvious if you use the %z display option to see 
the UTC offset:


$ TZ=Asia/Shanghai date '+%Y%m%d%H %z' -d '1990-04-13 12 35 hours'
1990041423 +0800
$ TZ=Asia/Shanghai date '+%Y%m%d%H %z' -d '1990-04-13 12 36 hours'
1990041501 +0900

So this is not a bug, but a hazard of making precise date calculations 
around DST boundaries. Please read the FAQ discussion here:

http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e


Cheers,
Phil

Re: bug in date command

[Pádraig Brady]

Prog piR wrote:
 date +%^B gives the month in capital letters
 
 but in french august is août, and the accentued letter is not capitalized
 
 date +%^B gives AOûT instead of AOÛT

Nor does tr '[:lower:]' '[:upper:]' support multibyte chars either,
I'll add that to the list of multibyte stuff I need to look at.

 In addition, is there any option to have lowercase ?

The ^ and # flags are GNU extensions.
I guess for consistency we could add lower.

cheers,
Pádraig.

Re: Bug in 'date'

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Sergey Trubnikov on 3/30/2009 5:54 AM:
 Hi!
 I'am find a some strange bug in a 'date' program:)
 
 Look at this:
 [...@localhost Shell]$ date +%Y-%m-%d
 2009-03-30
 [...@localhost Shell]$ date -d 0 day -1 month +%Y-%m-%d
 2009-03-02
 but must be 2009-02-30 O_o

Before you complain, think about it - there is no February 30th.

Not a bug - you are moving by a 30-day 'month' but in the context of a
28-day or 31-day calendar segment.  This behavior is documented, and there
is no choice we can make that will fit everyone's needs (similar things
happen 'yesterday' subtracts 24 hours, even when the previous day was a
23-hour day due to daylight savings).  Both choices (figure out whether
the adjustment falls over a special-case boundary, to affect only one
calendar unit, vs. always treat a relative date as a fixed length of time
without regards to special cases) have their users, and at this point,
existing scripts depend on the existing choice.  So all we can suggest is
to avoid special times (compute 'yesterday' relative to noon, not one
minute after midnight; compute 'last month' relative to the 15th, not the
first).

If you have a suggestion on how to improve the FAQ, we are all ears.
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknQtWcACgkQ84KuGfSFAYBFowCglF5kTuU6glOOZGp2TZGj3br2
f+0AnjXLz9KuI006suZx8vX3o62WXY7Q
=rTrx
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date-command

[Bob Proulx]

Bas Mijling wrote:
 I use the date command to find the next day of a date written in the 
 'mmdd' format,
 e.g. for 25 October 2008

Just a side note: I like using %F for this type of string.

 This works perfect for all dates I used so far, apart from a (strangely 
 enough) 20081026
 date -d 20081026 1 days +%Y%m%d
 returns the same datecode: 20081026

You probably want to do the date calculation at noon to avoid problems
near time change since one day is really 24 hours.  And working in UTC
is safer.

Try these:

  date -u -d 2008-10-26 12:00 UTC +1 days +%Y%m%d

  date -u -d 20081026 12:00 + 1 days +%Y%m%d

Please also see this FAQ item as you may be experiencing one of the
problems described there.

  
http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e

And the documentation here:

  info coreutils General date syntax

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date-command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bob Proulx on 3/13/2009 3:03 PM:
 This works perfect for all dates I used so far, apart from a (strangely 
 enough) 20081026
 date -d 20081026 1 days +%Y%m%d
 returns the same datecode: 20081026
 
 You probably want to do the date calculation at noon to avoid problems
 near time change since one day is really 24 hours.  And working in UTC
 is safer.

In case you missed the previous message on this topic, the key point is
that not all days are 24 hours - depending on your time zone, some days
are 23 or 25 hours thanks to daylight savings, while the 1 days modifier
always operates in terms of 24 hours.
http://lists.gnu.org/archive/html/bug-coreutils/2009-03/msg00160.html

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm6/2kACgkQ84KuGfSFAYD2TgCgyR2XtkUcdKAcMYVvkyUtIsMi
I60AnjIKS6lgIPS0ErdOPaK6a2MiO/KH
=TRW5
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in date command

[Bob Proulx]

Bob Kline wrote:
 The date command reports the wrong ISO week number in some cases.  For
 example:
 
 $ date -d 2008-12-31 +%Y%V
 200801
 
 Clearly the last day of the year can't be in the first week of that
 year.

According to ISO 8601 it can.  See the official standard for the
authoritative details but wikipedia has a good summary.

  http://en.wikipedia.org/wiki/ISO_8601

Weeks begin with Monday and end on Sunday.  Week 01 is the week with
the year's first Thursday in it.

The GNU Coreutils date %V documentation says:

  `%V'
   week number of year with Monday as first day of the week as a
   decimal (`01'...`53').  If the week containing January 1 has four
   or more days in the new year, then it is considered week 1;
   otherwise, it is week 53 of the previous year, and the next week
   is week 1.  (See the ISO 8601 standard.)

Perhaps for your purposes (you didn't say what you purpose was) you
wanted to use %G%V?

  $ date -d 2008-12-31 +%G%V
  200901

Personally I prefer %F (a GNU extension) best.

  $ date -d 2008-12-31 +%F
  2008-12-31

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in date command

[Bob Proulx]

Eric Blake wrote:
 There seems to always be a rash of bug reports about date at the
 turn of the year (and also around daylight savings changes), due to
 the large number of people who don't realize the subtleties
 involved.  Perhaps we should create a FAQ entry with the most common
 of these reports.

Good idea!  I have just now done so and have replaced the old and long
stale old date entry (which was tiny and if you don't remember just
said that things had been updated after 2000) with one that is quite a
bit longer now.  :-)

  
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

How does that look?

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in date command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bob Proulx on 1/7/2009 3:12 PM:
   
 http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
 
 How does that look?

A couple of nits:

The parsing of dates with date --date=STRING is a GNU extension and not
covered by any standards beyond those to which GNU holds itself.  Not
entirely true any longer, now that POSIX 2008 requires that 'touch -d
STRING' parse a limited format of ISO dates, and we implement that with
the same date parsing engine as our (true GNU extension) 'date -d'.  On
the other hand, since we don't yet accept 'T' in an ISO date (POSIX allows
the alternative of space, which we do parse), there is still some hacking
to be done on getdate.y.  But yes, in general, we parse many more STRINGs
as dates than what POSIX requires.

The %Y and %U options work in combination.  To be fair, we should state
that the %Y and your choice of %U/%W work in combination (%W if you want
Monday, %U if you want Sunday as the first day of the week).

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkllaeEACgkQ84KuGfSFAYBYkwCgmFdOrkSBFAbXtEBrTDe0WDCO
DJ8Ani9RwIt1Cb6vP1cBoF289isk0Hdr
=gJI1
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in date command

[Bob Proulx]

Eric Blake wrote:
 A couple of nits:
 
 The parsing of dates with date --date=STRING is a GNU extension and not
 covered by any standards beyond those to which GNU holds itself.  Not
 entirely true any longer, now that POSIX 2008 requires that 'touch -d
 STRING' parse a limited format of ISO dates, and we implement that with
 the same date parsing engine as our (true GNU extension) 'date -d'.

Good point.  I added the following to the previous description.

  However @command{touch -d STRING} is defined by POSIX and is
  implemented with the same date string parsing code.  Therefore you
  can expect that similar rules will apply to both.

 The %Y and %U options work in combination.  To be fair, we should state
 that the %Y and your choice of %U/%W work in combination (%W if you want
 Monday, %U if you want Sunday as the first day of the week).

As per your suggestion I have added discussion of %W too.

  The @option{%Y} and @option{%U} or @option{%W} options work in
  combination.  (Use @option{%U} for weeks starting with Sunday or
  @option{%W} for weeks starting with Monday.)  The ISO @option{%G} and
  @option{%V} options work in combination.  Mixing them up creates
  confusion.  Instead use @option{%Y} and @option{%U}/@option{%W}
  together or use @option{%G} and @option{%V} together.

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in date?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Enrique Arizón Benito on 9/9/2008 4:45 AM:
 ||# ||date -s 1970-01-01 00:00:01
 
 doesn't work.

Thanks for the report.  In which way does it not work?  What error
message, if any, is printed?  What did you expect to happen, when compared
to what actually happened?

 
 In general any hour value amongst 01-23 works. 00 fails!
 
 ||Is that the expected behaviour?

It's hard to say without more details.  Perhaps your timezone is a factor,
where all times 01:00:00 and above normalize to a positive number of
seconds since the epoch, but where 00:00:01 normalizes to a time less than
zero given your current timezone, and your system rejects attempt to set
time to a negative value?

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjGZrkACgkQ84KuGfSFAYBxqQCgqkhgoKv2qQ9XWJkzdkE43VQE
f/4An0Ma6O6dTMSuMEfx8SKyDm5kJv3j
=una0
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in date?

[Enrique Arizón Benito]

Eric Blake wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Enrique Arizón Benito on 9/9/2008 4:45 AM:
  

||# ||date -s 1970-01-01 00:00:01

doesn't work.



Thanks for the report.  In which way does it not work?  What error
message, if any, is printed?  What did you expect to happen, when compared
to what actually happened?

  

Upps, I forgot it.

 #date -s 1970-01-01 00:00:01
 date: cannot set date: Invalid argument
 Thu Jan 1 00:00:01 CET 1970

Curiosly after the Invalid argument error, date properly prints the new 
hour but doesn't change it.

That's what makes me think it's really a bug.


In general any hour value amongst 01-23 works. 00 fails!

||Is that the expected behaviour?



It's hard to say without more details.  Perhaps your timezone is a factor,
where all times 01:00:00 and above normalize to a positive number of
seconds since the epoch, but where 00:00:01 normalizes to a time less than
zero given your current timezone, and your system rejects attempt to set
time to a negative value?
  


Is there any way to known which timezone date uses?
My system environment variables have nothing related to time zone.
/etc/timezone indicates Europe/Paris. I remove such file and log in 
again,

but the same error arises.

Regards and thanks in advance for your help!

Enrique

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjGZrkACgkQ84KuGfSFAYBxqQCgqkhgoKv2qQ9XWJkzdkE43VQE
f/4An0Ma6O6dTMSuMEfx8SKyDm5kJv3j
=una0
-END PGP SIGNATURE-
  


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in date?

[James Youngman]

On Tue, Sep 9, 2008 at 1:47 PM, Enrique Arizón Benito
[EMAIL PROTECTED] wrote:

 Upps, I forgot it.

  #date -s 1970-01-01 00:00:01
  date: cannot set date: Invalid argument

It looks like date is simply reporting an error that it received from
the operating system.   The strace utility (or some platform-specific
replacement if you are not using Linux) should be able to confirm
this.

  Thu Jan 1 00:00:01 CET 1970

 Curiosly after the Invalid argument error, date properly prints the new hour
 but doesn't change it.

This is almost certainly because the date program understands the date
you refer to, but failed in its attempt to set the system clock to
that value.

 That's what makes me think it's really a bug.

More likely it's because CET is 1h ahead of UTC and therefore the time
you specified is before the Epoch.But Eric already said that, so
perhaps you ruled out that possibility but did not say so.

James


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date (coreutils-6.12)

[David Chin]

ah, i should have known. thanks for the response!

--dave


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date (coreutils-6.12)

[Bob Proulx]

David Chin wrote:
 Eli Rykoff [EMAIL PROTECTED] told me about this, and I verified with
 coreutils-6.12 compiled with gcc-4.3.0 on Fedora Core 9.
 coreutils-6.10 which comes with Fedora Core 9 also has this bug.

Thank you for your report.  However I do not see any bug here.

 To reproduce, do this:
  date -d 2006-04-02 02:30:00

You didn't say but I assume you are seeing this following output and
are confused by it?  This is the expected output in a US timezone.

  date: invalid date `2006-04-02 02:30:00'

First, you didn't specify a timezone.  My timezone is US/Mountain and
that is an invalid date in my timezone.  Let me assume that you are
using a US timezone.  If you check your calender you will find that
daylight savings changed on that date and there wasn't a 2:30 on that
day.  Because Using zdump to output the timezone data is helpful here.

  $ zdump -v US/Mountain | grep 2006
  US/Mountain  Sun Apr  2 08:59:59 2006 UTC = Sun Apr  2 01:59:59 2006 MST 
isdst=0 gmtoff=-25200
  US/Mountain  Sun Apr  2 09:00:00 2006 UTC = Sun Apr  2 03:00:00 2006 MDT 
isdst=1 gmtoff=-21600
  US/Mountain  Sun Oct 29 07:59:59 2006 UTC = Sun Oct 29 01:59:59 2006 MDT 
isdst=1 gmtoff=-21600
  US/Mountain  Sun Oct 29 08:00:00 2006 UTC = Sun Oct 29 01:00:00 2006 MST 
isdst=0 gmtoff=-25200

This shows that on my system MDT begins on Apr 2 03:00:00 2006 MDT
with the last second before being Apr 2 01:59:59 2006 MST and
therefore 2006-04-02 02:30:00 cannot be a valid time in the US.  It
may be a valid time elsewhere in another timezone.  (I should have
asked how such a date string was generated in the first place given
that it is an invalid string.)

Of course there is no trouble at all in the UTC timezone.

  $ date -u -d 2006-04-02 02:30:00 UTC
  Sun Apr  2 02:30:00 UTC 2006

 As a comparison, do this:
 date -d 2006-04-01 02:30:00

Sure.  That was the day before and that day *did* have a 2:30am MST.
And the day after would be okay too.

Now you know why UTC has so much going for it and why I am not a fan
of DST.  :-)

And a fun time was had by all with time, dates and calendars.  :-)

Hope that helps,
Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug-coreutils date command

[Richard Narum]

Thanks for your prompt comments.  I did not have tzcode installed.  I installed 
2007h-1 and I had to use TZ=America/Chicago and all is well now.  I checked 
dates back to 1974 and they match to a tee.

Thanks again,

Rick
--

- Original Message -
From: Eric Blake [EMAIL PROTECTED]
To: Philip Rowlands [EMAIL PROTECTED]
Cc: Richard Narum [EMAIL PROTECTED], bug-coreutils@gnu.org
Sent: Monday, December 3, 2007 8:52:31 PM (GMT-0600) America/Chicago
Subject: Re: bug-coreutils date command

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Philip Rowlands on 12/3/2007 6:23 PM:
 I am currently running GNU coreutils 6.9 with Cygwin on Windows XP
 version CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57.
 
 What version of the tzcode package do you have, if any?
 /var/log/setup.log contains this info on my Cygwin installation - I
 don't know the proper way to check, which the installer uses.

Checking cygwin packages is as simple as:

cygcheck -c tzcode

If you don't have 2007h-1, you should probably upgrade.  Furthermore, this
is unlikely to be a bug in coreutils; if the problem persists after
upgrading, then the bug lies in the timezone database or in your
environment selecting which portion of the database to use.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHVMDv84KuGfSFAYARAjnWAKCTzLayxtCP+bjHsgylZrmN6Pwq4ACeKWVl
YYd6eOlF9xdX5PmvdlmBh6Y=
=/oUT
-END PGP SIGNATURE-



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug-coreutils date command

[Philip Rowlands]

On Mon, 3 Dec 2007, Richard Narum wrote:

I'm not sure if you would call this a bug or not but I'm wondering why 
the GNU date command doesn't have the correct time adjustment for 
daylight savings from years past on its output when using an input 
date string to generate its output.


I am currently running GNU coreutils 6.9 with Cygwin on Windows XP 
version CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57.


What version of the tzcode package do you have, if any? 
/var/log/setup.log contains this info on my Cygwin installation - I 
don't know the proper way to check, which the installer uses.



The following commands shows dates when CST switches to CDT and back.

$ export TZ=CST6CDT


What does this mean? Specifically, without giving the full syntax (e.g. 
EST5EDT4,116/2:00:00,298/2:00:00) how is the C library to know what 
rules are passed by Congress regarding the DST switchover date?


The usual way is to have a large collection of files giving the 
historical date patterns and gmt offsets. If your system has an old 
(pre-2005?) version of these files, or none at all, date and the 
localtime(3) function it calls can't help.


Could someone shed some light on why maybe additional rules are not 
applied?


I remember being told once that the CST8CDT pattern was now broken by 
the Energy Policy Act changes, but I can't find a reference. The best 
thing to do is avoid that syntax and use the location-based files 
instead; e.g. America/Chicago for Central Standard/Daylight Time.



Cheers,
Phil


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug-coreutils date command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Philip Rowlands on 12/3/2007 6:23 PM:
 I am currently running GNU coreutils 6.9 with Cygwin on Windows XP
 version CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57.
 
 What version of the tzcode package do you have, if any?
 /var/log/setup.log contains this info on my Cygwin installation - I
 don't know the proper way to check, which the installer uses.

Checking cygwin packages is as simple as:

cygcheck -c tzcode

If you don't have 2007h-1, you should probably upgrade.  Furthermore, this
is unlikely to be a bug in coreutils; if the problem persists after
upgrading, then the bug lies in the timezone database or in your
environment selecting which portion of the database to use.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHVMDv84KuGfSFAYARAjnWAKCTzLayxtCP+bjHsgylZrmN6Pwq4ACeKWVl
YYd6eOlF9xdX5PmvdlmBh6Y=
=/oUT
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in date command

[Santiago Vila]

On Wed, 21 Nov 2007, Eric Blake wrote:

 So it looks like a lot of work still needs doing.

Indeed. Thanks for the reminder.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in date command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Toni on 11/21/2007 2:28 PM:
 date +%R does not show seconds

Not a bug, since that is what it is documented to do:

$ date --help | grep %R
  %R   24-hour hour and minute; same as %H:%M

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHRRKw84KuGfSFAYARAqyPAJ4iR8cIpHCH9skbABJdAa2LiMRjagCg0ojS
gZ03kXg7uvh3Xlk98JpimFE=
=8ynR
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in date command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[Please keep replies on the list, so that others can read about it]

[Adding the last-documented Spanish translation team]

According to Toni on 11/21/2007 10:32 PM:
 According to Toni on 11/21/2007 2:28 PM:
 date +%R does not show seconds

 Not a bug, since that is what it is documented to do:

 $ date --help | grep %R
   %R   24-hour hour and minute; same as %H:%M



 Then it's a translation mistake of the spanish documentation.
  
 %R la hora, en formato de 24 horas (p.e. 28:55:01 )
 
 Sorry for the false alarm.

Not a problem - translation bugs won't get fixed if they aren't reported
to the translation team.  However,
http://translationproject.org/PO-files/es/coreutils-6.9.es.po claims that
the most recent translation for coreutils was completed in 2004 for
version 5.2.1; and the translation lacks even the usual message that
should appear in 'date --version' output with both bug-coreutils and the
translation team bug reporting addresses.  So it looks like a lot of work
still needs doing.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHRRdh84KuGfSFAYARAqnmAJ9PjXZNMLvYtvDxBomf+/IIwqFnRgCgxIUn
DQSqb2U0D1XrBzGg2qfTuyw=
=1VlS
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [bug #21455] date --date +test fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

[Jim Meyering]

Philip Rowlands [EMAIL PROTECTED] wrote:
 On Tue, 30 Oct 2007, Jim Meyering wrote:
 I'm hardly the authority on such TZ things, but would have thought
 the invalid zones are those two intervals (one per line), which are
 nominally two and one hours long.  It looks like they're two
 different views of the same two-real-hour interval.  The first uses
 the DST (isdst=1) times, and the second non-DST times.

 Date's -d option interprets an empty string just like 0, which is
 interpreted as 00:00 in the current day.

 Ah, that makes the problem easier to present:

 $ export TZ=Europe/Paris
 $ export LD_PRELOAD=./clock_gettime.so
 $ FAKETIME=1193533200 date -d 
 date: invalid date `'
 $ FAKETIME=1193533200 date -d 0
 Sun Oct 28 00:00:00 CEST 2007

 -d  and -d 0 are not equivalent in this case.

Hi Phil,

Thanks for keeping this going.

I tracked the difference to how the get_date function sets the
pc.times_seen member.  That controls whether a tm.tm_isdst is initialized
to -1 (yes, for a date string of 0, no for the empty string).
That difference is what leads to a later mismatch between tm0 and tm,
causing mktime_ok to return false and thus making get_date fail.

The fix makes the code match the documentation by handling this case
as well as the case of a string containing only white space or a bare
TZ=... specification.

It'd be good to add a test for this.
Would you like to contribute a test case for gnulib,
since you've done most of the work already?

Paul owns the getdate module, so I'll wait for his ok
before pushing this:


Treat an empty date string exactly like 0.

* lib/getdate.y (get_date): Once any isspace or TZ= prefix is consumed,
if the remaining date string (to be parsed) is empty, use 0.

Signed-off-by: Jim Meyering [EMAIL PROTECTED]
---
 lib/getdate.y |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/lib/getdate.y b/lib/getdate.y
index 80e484d..591c7f0 100644
--- a/lib/getdate.y
+++ b/lib/getdate.y
@@ -1238,6 +1238,12 @@ get_date (struct timespec *result, char const *p, struct 
timespec const *now)
  }
 }

+  /* As documented, be careful to treat the empty string just like
+ a date string of 0.  Without this, an empty string would be
+ declared invalid when parsed during a DST transition.  */
+  if (*p == '\0')
+p = 0;
+
   pc.input = p;
   pc.year.value = tmp-tm_year;
   pc.year.value += TM_YEAR_BASE;
--
1.5.3.4.452.g09149


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [bug #21455] date --date +test fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

[Paul Eggert]

Jim Meyering [EMAIL PROTECTED] writes:

   * lib/getdate.y (get_date): Once any isspace or TZ= prefix is consumed,
   if the remaining date string (to be parsed) is empty, use 0.

Sheesh, and I was trying to look at getdate's guts, which is a big mistake.
Thanks for the patch; it's much simpler.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [bug #21455] date --date +test fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

[Jim Meyering]

Paul Eggert [EMAIL PROTECTED] wrote:

 Jim Meyering [EMAIL PROTECTED] writes:

  * lib/getdate.y (get_date): Once any isspace or TZ= prefix is consumed,
  if the remaining date string (to be parsed) is empty, use 0.

 Sheesh, and I was trying to look at getdate's guts, which is a big mistake.
 Thanks for the patch; it's much simpler.

I've pushed it.

FYI, I started by comparing ltrace output from these commands
(thanks to Phil for the clock_gettime replacement):

TZ=Europe/Paris LD_PRELOAD=./clock_gettime.so FAKETIME=1193533200 \
  diff -u (ltrace ./date -d '' 21) \
  (ltrace ./date -d 0 21)

That suggested early mktime results differed.
Then debug each and see where/why the mktime inputs diverged:

TZ=Europe/Paris LD_PRELOAD=./clock_gettime.so FAKETIME=1193533200 \
  gdb --args ./date -d ''

TZ=Europe/Paris LD_PRELOAD=./clock_gettime.so FAKETIME=1193533200 \
  gdb --args ./date -d 0


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [bug #21455] date --date +test fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

[Jim Meyering]

Philip Rowlands [EMAIL PROTECTED] wrote:
...
 $ zdump -v Europe/Paris
 Europe/Paris  Sun Oct 28 00:59:59 2007 UTC = Sun Oct 28 02:59:59 2007 CEST 
 isdst=1 gmtoff=7200
 Europe/Paris  Sun Oct 28 01:00:00 2007 UTC = Sun Oct 28 02:00:00 2007 CET 
 isdst=0 gmtoff=3600

 In Europe/Paris, the boundaries of invalid times are 1193533200 -
 1193612399 inclusive, or
 Sun Oct 28 02:00:00 CET 2007 - Sun Oct 28 23:59:59 CET 2007
...
 This corresponds to the first second of winter time isdst=0 and
 persists for the rest of the logical day. I'm wary about diving around
 in unfamiliar code - perhaps someone more familiar with date parsing
 knows how date -d  is supposed to be treated, and what the problem
 is here?

Hi Phil,

I'm hardly the authority on such TZ things, but would have thought
the invalid zones are those two intervals (one per line), which
are nominally two and one hours long.  It looks like they're two
different views of the same two-real-hour interval.  The first uses
the DST (isdst=1) times, and the second non-DST times.

Date's -d option interprets an empty string just like 0,
which is interpreted as 00:00 in the current day.

This is already documented:

$ grep empt getdate.texi
A @dfn{date} is a string, possibly empty, containing many items
ambiguity arises.  The empty string means the beginning of today (i.e.,

Or, in info coreutils date general

27.1 General date syntax


A date is a string, possibly empty, containing many items separated
by whitespace.  The whitespace may be omitted when no ambiguity arises.
The empty string means the beginning of today (i.e., midnight).  Order


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [bug #21455] date --date +test fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

[Philip Rowlands]

On Tue, 30 Oct 2007, Jim Meyering wrote:

I'm hardly the authority on such TZ things, but would have thought the 
invalid zones are those two intervals (one per line), which are 
nominally two and one hours long.  It looks like they're two different 
views of the same two-real-hour interval.  The first uses the DST 
(isdst=1) times, and the second non-DST times.


Date's -d option interprets an empty string just like 0, which is 
interpreted as 00:00 in the current day.


Ah, that makes the problem easier to present:

$ export TZ=Europe/Paris
$ export LD_PRELOAD=./clock_gettime.so
$ FAKETIME=1193533200 date -d 
date: invalid date `'
$ FAKETIME=1193533200 date -d 0
Sun Oct 28 00:00:00 CEST 2007

-d  and -d 0 are not equivalent in this case.


Cheers,
Phil


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [bug #21455] date --date +test fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

[Philip Rowlands]

On Mon, 29 Oct 2007, Mischa Molhoek wrote:

ok, here is the text version, because the image is remove by accident 
:)


It's simpler to debug problems reported by text, not pictures.


[titan: mischa] ~ date --version
date (GNU coreutils) 5.97
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.

Written by David MacKenzie.
[titan: mischa] ~ date --date  +test
test

[titan: mischa] ~ sudo date -s Sun Oct 28 22:00:53 CET 2007
Sun Oct 28 22:00:53 CET 2007

[titan: mischa] ~ date --date  +test
date: invalid date `'


You don't need the +test, it's invalid by itself :)


[titan: mischa] ~ sudo rdate -s ntp.xs4all.nl

[titan: mischa] ~ date
Mon Oct 29 12:08:41 CET 2007



[titan: mischa] ~ date --date  +test
test


You don't give your timezone explicitly, so I'm going to guess you're in 
a region which follows Central European Time / Central European Summer 
Time.


I hacked up the following to avoid resetting my system clock all over 
the place:


- clock_gettime.c ---
#include stdlib.h
#include time.h
#include errno.h

int clock_gettime(clockid_t clk_id, struct timespec *tp) {
if (clk_id != CLOCK_REALTIME) {
errno = EINVAL;
return -1;
}
char *faketime = getenv(FAKETIME);
if (! faketime ) {
errno = EINVAL;
return -1;
}
if (tp) {
tp-tv_nsec = 0;
tp-tv_sec = atol(faketime);
}
return 0;
}
-

gcc -c -fPIC clock_gettime.c -D_GNU_SOURCE
gcc -shared -fPIC -o clock_gettime.so clock_gettime.o
for anyone following at home.

Firstly, let's see what date -d  does?

$ date -d 
Mon Oct 29 00:00:00 GMT 2007

This has shown my current time wound back to the previous midnight. (I 
can't find the documentation which describes this, but let's continue 
regardless.)


$ export TZ=Europe/Paris
$ export FAKETIME=1193605253; LD_PRELOAD=./clock_gettime.so date -d 
date: invalid date `'

Smells like a DST issue, are we in a DST change?

$ zdump -v Europe/Paris
Europe/Paris  Sun Oct 28 00:59:59 2007 UTC = Sun Oct 28 02:59:59 2007 CEST 
isdst=1 gmtoff=7200
Europe/Paris  Sun Oct 28 01:00:00 2007 UTC = Sun Oct 28 02:00:00 2007 CET 
isdst=0 gmtoff=3600

In Europe/Paris, the boundaries of invalid times are 1193533200 - 
1193612399 inclusive, or

Sun Oct 28 02:00:00 CET 2007 - Sun Oct 28 23:59:59 CET 2007

If I try the same thing in Europe/Dublin, invalid times become
1193533200 - 1193615999 inclusive, or
Sun Oct 28 01:00:00 GMT 2007 - Sun Oct 28 23:59:59 GMT 2007

This corresponds to the first second of winter time isdst=0 and 
persists for the rest of the logical day. I'm wary about diving around 
in unfamiliar code - perhaps someone more familiar with date parsing 
knows how date -d  is supposed to be treated, and what the problem is 
here?



Cheers,
Phil


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [bug #21455] date --date +test fails ONLY WITHIN CERTAIN TIME PERIOD #$%^%

[Bob Proulx]

Philip Rowlands wrote:
 I hacked up the following to avoid resetting my system clock all over 
 the place:

I have found the FakeTime Preload Library to be very useful for these
things.  Let me recommend it as an alternative to setting the system
time.  Perhaps you will find it useful too.

  http://www.code-wizards.com/projects/libfaketime/

It allows useful tests such as this to be performed completely in user
space.

  LD_PRELOAD=./libfaketime.so.1 FAKETIME=2007-10-28 01:00:00 date -u -R
  Sun, 28 Oct 2007 01:00:00 +

 Smells like a DST issue, are we in a DST change?

Agreed.

 $ zdump -v Europe/Paris
 ...Very nice analysis trimmed...

That was a very nice job of analysis.

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in 'date -d': timezone trouble

[Philip Rowlands]

On Wed, 12 Sep 2007, PF wrote:


% date -d 07-09-10 10:45:43 + 1 minute
Mon Sep 10 03:45:43 PDT 2007


Try taking out the plus sign - date interprets this as a timezone 
specifier.



Cheers,
Phil


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in 'date -d': timezone trouble

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Philip Rowlands on 9/12/2007 6:53 AM:
 On Wed, 12 Sep 2007, PF wrote:
 
 % date -d 07-09-10 10:45:43 + 1 minute
 Mon Sep 10 03:45:43 PDT 2007
 
 Try taking out the plus sign - date interprets this as a timezone
 specifier.

Indeed.  This question has been asked before:
http://lists.gnu.org/archive/html/bug-coreutils/2007-07/msg00071.html

Meanwhile, you may want to consider upgrading.  The latest stable version
of coreutils is 6.9.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG5+cO84KuGfSFAYARAjRTAKCD7Qw1m5Pj6fs2a8IeQQLQKA3sLACfY6Vj
l2DQYhsTtjTyODsg2aIc68s=
=Q+5j
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Bug in 'date -d': timezone trouble

[Philip Rowlands]

On Wed, 12 Sep 2007, Eric Blake wrote:


% date -d 07-09-10 10:45:43 + 1 minute
Mon Sep 10 03:45:43 PDT 2007


Try taking out the plus sign - date interprets this as a timezone
specifier.


Indeed.  This question has been asked before:
http://lists.gnu.org/archive/html/bug-coreutils/2007-07/msg00071.html


Would it be worthwhile adding yydebug support to date (and touch) with, 
say, a --date-debug flag? I tried turning it on and the output is 
confusingly dense, not even printing the token in all cases.


I see from the bison manual that a custom yyprint function can be 
provided, but I'm not familiar enough with parsers to suggest one.



Cheers,
Phil


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date utillity

[Philip Rowlands]

On Mon, 31 Jul 2006, Vladislav ZItikis wrote:


I think, I find a bug in date calculations.
This is example for demonstration:
---

[EMAIL PROTECTED] date
Mon Jul 31 17:12:57 MSD 2006

[EMAIL PROTECTED] date -d 1 month ago +%m
07
[EMAIL PROTECTED] date -d 2 month ago +%m
05
[EMAIL PROTECTED]

--
I think, date -d 1 month ago +%m must return to me '06' but not '07'


Please see section 27.6 of the date manual, Relative items in date 
strings, which states:


The fuzz in units can cause problems with relative items.  For
example, `2003-07-31 -1 month' might evaluate to 2003-07-01, because
2003-06-31 is an invalid date.  To determine the previous month more
reliably, you can ask for the month before the 15th of the current
month.


Cheers,
Phil


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date: --rfc-3339=seconds and --rfc-3339=ns options do *not* output timestamps in RFC 3339 format

[Romain Lenglet]

Paul Eggert wrote:
 Romain Lenglet [EMAIL PROTECTED] writes:
  ISO 8601 states that the T may be omitted under some
  circumstances.

 Omitted, not replaced by a space.

OK, you're right.

 ISO 8601 section 4.4 is 
 quite clear: it states The space character shall not be used
 in the representations.

OK. And the NOTE in section 5.4.1 is clear also.

 RFC 3339 is equally clear: it says 
 Applications using this syntax may choose, for the sake of
 readability, to specify a full-date and full-time separated by
 (say) a space character. Which is exactly what GNU date is
 doing.

This interpretation of the NOTE in section 5.6 is not shared by 
everyone. e.g. cf. 
http://validator.w3.org/feed/docs/error/InvalidRFC3339Date.html
http://lists.infodrom.org/infodrom-sysklogd/2003/0023.html

And in this NOTE, replacing T by a space is only one example 
((say)). This NOTE then allows to replace T by *(say)* an 
underscore. How will you parse that? If one follows this, for 
the sake of readability, one can specify a full-date and 
full-time separated by *(say)* just anything. How would you 
parse the just anything that anyone seems to be allowed to use 
by this NOTE?

Since this NOTE is ambiguous (SHOULD in the beginninig of 
section 5.6, and the ABNF makes T mandatory, but in this 
NOTE: may, (say)), let's stick to the ABNF, which makes 
the T mandatory. It is the safest bet.


Even when considering that replacing T with a space seems to be 
allowed by this NOTE in RFC 3339, making T mandatory seems to 
be the general consensus:
- XMLSchema's dateTime type conforms to RFC 3339, except that it 
makes the timezone optional, and allows for time 24:00:00, and 
it makes T mandatory.
- The Atom standard (RFC 4287) uses RFC 3339, but makes the T 
explictly mandatory.
- W3C's datetime format (another profile of ISO 8601, similar to 
RFC 3339) makes the T mandatory:
http://www.w3.org/TR/1998/NOTE-datetime-19980827

I know that you seem to have problems parsing this T, but I 
don't agree that this is a good enough reason for not outputing 
a format that follows the (IMHO) general consensus.

Could you point me to other discussions or standards which allow 
to replace T with anything else? (except GNU date, of course)

 What real-world need is driving this bug report?

None. I was surprised that --rfc-3339=seconds does not follow the 
consensus. And using T instead of a space is more convenient 
when generating filenames with a timestamp, because it can 
easily be selected with the mouse by double-clicking on the 
screen. ;-)

 Would this 
 need be satisfied by the following command instead?

 date -u +'%Y-%m-%dT%H:%M:%SZ'

Yes. I am using this command. Well,
date -u +'%Y-%m-%dT%H:%M:%S%:z'
to be correct.

 This command generates ISO-8601-conforming time stamps on any
 POSIX-conforming host.  It's far more standard than anything
 else that's been proposed on this thread.

 Even if we were inclined to put in the T, your two-line
 patch would be incorrect, since it doesn't change the
 documentation to match the behavior.

Sorry, I didn't think about the documentation.

 And the patch also 
 breaks the round-trip property guaranteed by the current
 documentation.  Fixing this would be nontrivial.

Allright. Then remove the --rfc-3339 option. It's fine with me.
Sorry, I won't send you a patch for this, because this one would 
be more than 10 lines.


Regards,

-- 
Romain LENGLET


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date: --rfc-3339=seconds and --rfc-3339=ns options do *not* output timestamps in RFC 3339 format

[Paul Eggert]

Romain Lenglet [EMAIL PROTECTED] writes:

 This interpretation of the NOTE in section 5.6 is not shared by 
 everyone. e.g. cf. 
 http://validator.w3.org/feed/docs/error/InvalidRFC3339Date.html

The explanation for this URL explicitly states that it is applying an
additional check, over and above what RFC 3339 requires.  The content
of this element MUST conform to the date-time production as defined
in RFC 3339. In addition, an uppercase T character MUST be used to
separate date and time  So this URL underscores the point that
spaces are allowed by RFC 3339.

 http://lists.infodrom.org/infodrom-sysklogd/2003/0023.html

This reference also points out that they are specifying a subset of
RFC 3339, and that one of their extra restrictions (and not the only
such restriction) is that a T must be used instead of a space.

 And in this NOTE, replacing T by a space is only one example 
 ((say)). This NOTE then allows to replace T by *(say)* an 
 underscore. How will you parse that?

We don't parse arbitrary dates, but we do try to parse the dates that
we ourselves generate.

 Since this NOTE is ambiguous

Not really.  None of the references you've mentioned have
misinterpreted it.  They all agree that a space is allowed
in RFC 3339.

 making T mandatory seems to  be the general consensus:

Not here.

 Could you point me to other discussions or standards which allow 
 to replace T with anything else? (except GNU date, of course)

A simple Google search brought up this in the first page.

http://en.wikipedia.org/wiki/ISO_8601
http://www.mdspacegrant.org/iso_dates.html
http://www.cs.tut.fi/~jkorpela/iso8601.html
http://bugs.darcs.net/issue31
http://www.merlyn.demon.co.uk/datefmts.htm

The last reference is the most interesting, since it claims that ISO
8601:2004 allows a space!  I haven't verified this.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date: --rfc-3339=seconds and --rfc-3339=ns options do *not* output timestamps in RFC 3339 format

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Romain Lenglet on 5/3/2006 12:47 AM:
 Hi,
 
 RFC 3339 makes it *mandatory* to separate the date and time with 
 a T in timestamps. Cf. section 5.6 of RFC 3339, describing the 
 timestamp syntax in ABNF:
 
 date-time   = full-date T full-time

Hmm.  Are you sure about that?  My understanding was that we deprecated -I
for being non-compliant with ISO 8601 because RFC 3339 explicitly requires
that the 'T' NOT appear in the date.  Reread section 5.6 in RFC 3339,
which permits implementations to avoid 'T'.  See the threads here, where
the --rfc-3339 option was discussed, and later added:

http://lists.gnu.org/archive/html/bug-coreutils/2005-07/msg00186.html
http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00056.html

If you need the T, for now you can rely on the undocumented --iso-8601
option.

 
 I am not providing you a patch, since I don't want to go through 
 the administrative burden of copyright transfer for so little, 
 but here are the correct date formats for the RFC 3339 options:

If the patch is less than 10 lines, it is considered trivial and can be
applied without copyright assignment.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEWKgU84KuGfSFAYARAhceAJ9xoPDZHzWW8wm3C/t+xCQFu040OwCfbX3U
6E7EyVWfclsCg3ht54jLhlk=
=NMt2
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date: --rfc-3339=seconds and --rfc-3339=ns options do *not* output timestamps in RFC 3339 format

[Paul Eggert]

Romain Lenglet [EMAIL PROTECTED] writes:

 Replacing T with a space character is an option in ISO 8601, 
 but not in RFC 3339.

This is backwards.  ISO 8601 does its utmost to require T, but RFC
3339 explicitly contradicts this, saying in section 5.6 Applications
using this syntax may choose, for the sake of readability, to specify
a full-date and full-time separated by (say) a space character.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date: --rfc-3339=seconds and --rfc-3339=ns options do *not* output timestamps in RFC 3339 format

[Romain Lenglet]

Paul Eggert wrote:
 Romain Lenglet writes:
  Replacing T with a space character is an option in ISO
  8601, but not in RFC 3339.

 This is backwards.  ISO 8601 does its utmost to require T,
 but RFC 3339 explicitly contradicts this, saying in section
 5.6 Applications using this syntax may choose, for the sake
 of readability, to specify a full-date and full-time separated
 by (say) a space character.

Please don't cut out what does not suit you! ;-)
The full quotation is:
NOTE: ISO 8601 defines date and time separated by T. 
Applications using this syntax may choose, for the sake of 
readability, to specify a full-date and full-time separated by 
(say) a space character.
Here, this syntax refers to ISO 8601!
I admit that the wording is odd, and I first interpreted it 
wrong.


But it is unambiguous in Appendix A:
ISO 8601 states that the T may be omitted under some 
circumstances.  This grammar requires the T to avoid 
ambiguity.
Here, This grammar refers to the (slightly modified to make 
the T mandatory) complete syntax of ISO 8601, which is 
specified in Appendix A.
Which means, that ISO 8601 allows to replace T with a space, 
but RFC 3339 does not.

It is very unambiguous in the ABNF specifications, both in 
Appendix A (full ISO 8601 syntax, modified to disallow a space 
instead of T unlike ISO 8601), and in section 5.6 (RFC 3339 
syntax, which is a subset of the ISO 8601 syntax).
In Appendix A:
iso-date-time = date T time
In section 5.6:
date-time   = full-date T full-time

(That's why they used the ABNF notation: to avoid ambiguity!)

Both ISO 8601 and RFC 3339 allow the T, but RFC 3339 explicitly 
disallows to replace it with a space.
I hope that I clarified the situation? :-)

-- 
Romain LENGLET


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date: --rfc-3339=seconds and --rfc-3339=ns options do *not* output timestamps in RFC 3339 format

[Romain Lenglet]

Eric Blake wrote:
 According to Romain Lenglet on 5/3/2006 12:47 AM:
  Hi,
 
  RFC 3339 makes it *mandatory* to separate the date and time
  with a T in timestamps. Cf. section 5.6 of RFC 3339,
  describing the timestamp syntax in ABNF:
 
  date-time   = full-date T full-time

 Hmm.  Are you sure about that?  My understanding was that we
 deprecated -I for being non-compliant with ISO 8601 because
 RFC 3339 explicitly requires that the 'T' NOT appear in the
 date.  Reread section 5.6 in RFC 3339, which permits
 implementations to avoid 'T'.

I know, the NOTE is ambiguous in section 5.6. But the ABNF 
specifications are not. And the comments in Appendix A are not, 
either.

 See the threads here, where the 
 --rfc-3339 option was discussed, and later added:

 http://lists.gnu.org/archive/html/bug-coreutils/2005-07/msg001
86.html
 http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg000
56.html

I was aware of this thread. Thanks.

 If you need the T, for now you can rely on the undocumented
 --iso-8601 option.

  I am not providing you a patch, since I don't want to go
  through the administrative burden of copyright transfer for
  so little, but here are the correct date formats for the RFC
  3339 options:

 If the patch is less than 10 lines, it is considered trivial
 and can be applied without copyright assignment.

OK. Here is one patch of two lines. ;-)

-- 
Romain LENGLET
--- coreutils/ChangeLog	2006-05-03 19:11:05.0 +0900
+++ coreutils-rfc3339/ChangeLog	2006-05-04 13:12:07.084884824 +0900
@@ -1,3 +1,9 @@
+2006-05-04  Romain Lenglet  [EMAIL PROTECTED]
+
+	* src/date.c: In --rfc-3339=seconds and --rfc-3339=ns output
+	formats, replace the space with T to respect RFC 3339's ABNF
+	specification.
+
 2006-05-03  Jim Meyering  [EMAIL PROTECTED]
 
 	* Version 6.0-cvs.
--- coreutils/NEWS	2006-04-24 06:38:32.0 +0900
+++ coreutils-rfc3339/NEWS	2006-05-04 13:20:16.797437200 +0900
@@ -153,6 +153,10 @@
   tail -f once again works on a file with the append-only
   attribute (affects at least Linux ext2, ext3, xfs file systems)
 
+  date's options --rfc-3339=seconds and --rfc-3339=ns now output
+  timestamps with a T instead of a space between date and time, to
+  conform to RFC 3339's ABNF specification.
+
 * Major changes in release 5.93 (2005-11-06) [stable]
 
 ** Bug fixes
--- coreutils/THANKS	2006-05-03 19:11:25.0 +0900
+++ coreutils-rfc3339/THANKS	2006-05-04 13:12:50.990210200 +0900
@@ -422,6 +422,7 @@
 Rogier Wolff[EMAIL PROTECTED]
 Roland Huebner  [EMAIL PROTECTED]
 Roland Turner   [EMAIL PROTECTED]
+Romain Lenglet  [EMAIL PROTECTED]
 Ronald F. Guilmette [EMAIL PROTECTED]
 Ross Alexander  [EMAIL PROTECTED]
 Ross Paterson   [EMAIL PROTECTED]
--- coreutils/src/date.c	2006-01-09 05:45:54.0 +0900
+++ coreutils-rfc3339/src/date.c	2006-05-04 13:16:49.156003496 +0900
@@ -345,8 +345,8 @@
 	static char const rfc_3339_format[][32] =
 	  {
 		%Y-%m-%d,
-		%Y-%m-%d %H:%M:%S%:z,
-		%Y-%m-%d %H:%M:%S.%N%:z
+		%Y-%m-%dT%H:%M:%S%:z,
+		%Y-%m-%dT%H:%M:%S.%N%:z
 	  };
 	enum Time_spec i =
 	  XARGMATCH (--rfc-3339, optarg,
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date: --rfc-3339=seconds and --rfc-3339=ns options do *not* output timestamps in RFC 3339 format

[Paul Eggert]

Romain Lenglet [EMAIL PROTECTED] writes:

 ISO 8601 states that the T may be omitted under some 
 circumstances.

Omitted, not replaced by a space.  ISO 8601 section 4.4 is quite
clear: it states The space character shall not be used in the
representations.  RFC 3339 is equally clear: it says Applications
using this syntax may choose, for the sake of readability, to specify
a full-date and full-time separated by (say) a space character.
Which is exactly what GNU date is doing.

What real-world need is driving this bug report?  Would this need
be satisfied by the following command instead?

date -u +'%Y-%m-%dT%H:%M:%SZ'

This command generates ISO-8601-conforming time stamps on any
POSIX-conforming host.  It's far more standard than anything else
that's been proposed on this thread.

Even if we were inclined to put in the T, your two-line patch would
be incorrect, since it doesn't change the documentation to match the
behavior.  And the patch also breaks the round-trip property
guaranteed by the current documentation.  Fixing this would be
nontrivial.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [bug #16214] 'date -d' missets the hour using certain syntax

[Paul Eggert]

Dallman Ross [EMAIL PROTECTED] writes:

 My use of a year ago is not really valid syntax, then.

Yes it is.  It uses military time zone A, which is ahead of UTC by
one hour.  Hence the behavior that you observed.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date

[Paul Eggert]

Klaus Umbach [EMAIL PROTECTED] writes:

 in december 2002 I reported a bug in date:
 http://lists.gnu.org/archive/html/bug-sh-utils/2002-12/msg5.html
 today I saw, that in 5.2.1 it is not yet fixed.

It gets fixed faster if you submit a patch.  :-)

I installed this:

2005-07-21  Paul Eggert  [EMAIL PROTECTED]

* lib/getdate.y (relative_time): New type.
(RELATIVE_TIME_0): New constant.
(parser_control): Use relative_time instead of doing it ourselves.
(%union): Add new relative_time rel member.
(tYEAR_UNIT, tMONTH_UNIT, tHOUR_UNIT, tMINUTE_UNIT, tSEC_UNIT):
Now typeless.
(relunit, relunit_snumber): Now of type rel.
(zone, rel, relunit, get_date): Adjust to above changes.
* m4/getdate.m4 (gl_C_COMPOUND_LITERALS): New macro.
(gl_GETDATE): Use it.

Index: lib/getdate.y
===
RCS file: /fetish/cu/lib/getdate.y,v
retrieving revision 1.99
diff -p -u -r1.99 getdate.y
--- lib/getdate.y   14 May 2005 07:58:06 -  1.99
+++ lib/getdate.y   21 Jul 2005 21:55:40 -
@@ -137,6 +137,25 @@ enum { MERam, MERpm, MER24 };
 
 enum { BILLION = 10, LOG10_BILLION = 9 };
 
+/* Relative times.  */
+typedef struct
+{
+  /* Relative year, month, day, hour, minutes, seconds, and nanoseconds.  */
+  long int year;
+  long int month;
+  long int day;
+  long int hour;
+  long int minutes;
+  long int seconds;
+  long int ns;
+} relative_time;
+
+#if HAVE_COMPOUND_LITERALS
+# define RELATIVE_TIME_0 ((relative_time) { 0, 0, 0, 0, 0, 0, 0 })
+#else
+static relative_time const RELATIVE_TIME_0;
+#endif
+
 /* Information passed to and from the parser.  */
 typedef struct
 {
@@ -167,13 +186,7 @@ typedef struct
   struct timespec seconds; /* includes nanoseconds */
 
   /* Relative year, month, day, hour, minutes, seconds, and nanoseconds.  */
-  long int rel_year;
-  long int rel_month;
-  long int rel_day;
-  long int rel_hour;
-  long int rel_minutes;
-  long int rel_seconds;
-  long int rel_ns;
+  relative_time rel;
 
   /* Presence or counts of nonterminals of various flavors parsed so far.  */
   bool timespec_seen;
@@ -210,13 +223,16 @@ static long int time_zone_hhmm (textint,
   long int intval;
   textint textintval;
   struct timespec timespec;
+  relative_time rel;
 }
 
 %token tAGO tDST
 
-%token intval tDAY tDAY_UNIT tDAYZONE tHOUR_UNIT tLOCAL_ZONE tMERIDIAN
-%token intval tMINUTE_UNIT tMONTH tMONTH_UNIT tORDINAL
-%token intval tSEC_UNIT tYEAR_UNIT tZONE
+%token tYEAR_UNIT tMONTH_UNIT tHOUR_UNIT tMINUTE_UNIT tSEC_UNIT
+%token intval tDAY_UNIT
+
+%token intval tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN
+%token intval tMONTH tORDINAL tZONE
 
 %token textintval tSNUMBER tUNUMBER
 %token timespec tSDECIMAL_NUMBER tUDECIMAL_NUMBER
@@ -224,6 +240,8 @@ static long int time_zone_hhmm (textint,
 %type intval o_colon_minutes o_merid
 %type timespec seconds signed_seconds unsigned_seconds
 
+%type rel relunit relunit_snumber
+
 %%
 
 spec:
@@ -322,7 +340,15 @@ zone:
 tZONE
   { pc-time_zone = $1; }
   | tZONE relunit_snumber
-  { pc-time_zone = $1; pc-rels_seen = true; }
+  { pc-time_zone = $1;
+   pc-rel.ns += $2.ns;
+   pc-rel.seconds += $2.seconds;
+   pc-rel.minutes += $2.minutes;
+   pc-rel.hour += $2.hour;
+   pc-rel.day += $2.day;
+   pc-rel.month += $2.month;
+   pc-rel.year += $2.year;
+pc-rels_seen = true; }
   | tZONE tSNUMBER o_colon_minutes
   { pc-time_zone = $1 + time_zone_hhmm ($2, $3); }
   | tDAYZONE
@@ -430,74 +456,83 @@ date:
 rel:
 relunit tAGO
   {
-   pc-rel_ns = -pc-rel_ns;
-   pc-rel_seconds = -pc-rel_seconds;
-   pc-rel_minutes = -pc-rel_minutes;
-   pc-rel_hour = -pc-rel_hour;
-   pc-rel_day = -pc-rel_day;
-   pc-rel_month = -pc-rel_month;
-   pc-rel_year = -pc-rel_year;
+   pc-rel.ns -= $1.ns;
+   pc-rel.seconds -= $1.seconds;
+   pc-rel.minutes -= $1.minutes;
+   pc-rel.hour -= $1.hour;
+   pc-rel.day -= $1.day;
+   pc-rel.month -= $1.month;
+   pc-rel.year -= $1.year;
   }
   | relunit
+  {
+   pc-rel.ns += $1.ns;
+   pc-rel.seconds += $1.seconds;
+   pc-rel.minutes += $1.minutes;
+   pc-rel.hour += $1.hour;
+   pc-rel.day += $1.day;
+   pc-rel.month += $1.month;
+   pc-rel.year += $1.year;
+  }
   ;
 
 relunit:
 tORDINAL tYEAR_UNIT
-  { pc-rel_year += $1 * $2; }
+  { $$ = RELATIVE_TIME_0; $$.year = $1; }
   | tUNUMBER tYEAR_UNIT
-  { pc-rel_year += $1.value * $2; }
+  { $$ = RELATIVE_TIME_0; $$.year = $1.value; }
   | tYEAR_UNIT
-  { pc-rel_year += $1; }
+  { $$ = RELATIVE_TIME_0; $$.year = 1; }
   | tORDINAL tMONTH_UNIT
-  { pc-rel_month += $1 * $2; }
+  { $$ = RELATIVE_TIME_0; $$.month = $1; }
   | tUNUMBER tMONTH_UNIT
-  { pc-rel_month += $1.value * $2; }
+  { $$ = RELATIVE_TIME_0; $$.month = $1.value; }
   | tMONTH_UNIT
-  { pc-rel_month += 

Re: bug in date

[Klaus Umbach]

On Thu, Jul 21, 2005 at 15:02:24 -0700, Paul Eggert wrote:
 Klaus Umbach [EMAIL PROTECTED] writes:
 
  in december 2002 I reported a bug in date:
  http://lists.gnu.org/archive/html/bug-sh-utils/2002-12/msg5.html
  today I saw, that in 5.2.1 it is not yet fixed.
 
 It gets fixed faster if you submit a patch.  :-)

Sorry, I can't programm, I'm not a coder, I don't understand anything of
the stuff below. The only thing I can do, is report bugs, when I find them.
:-)

 
 I installed this:
 
 2005-07-21  Paul Eggert  [EMAIL PROTECTED]
 
   * lib/getdate.y (relative_time): New type.
   (RELATIVE_TIME_0): New constant.
   (parser_control): Use relative_time instead of doing it ourselves.
   (%union): Add new relative_time rel member.
   (tYEAR_UNIT, tMONTH_UNIT, tHOUR_UNIT, tMINUTE_UNIT, tSEC_UNIT):
   Now typeless.
   (relunit, relunit_snumber): Now of type rel.
   (zone, rel, relunit, get_date): Adjust to above changes.
   * m4/getdate.m4 (gl_C_COMPOUND_LITERALS): New macro.
   (gl_GETDATE): Use it.
 
 Index: lib/getdate.y
 ===
 RCS file: /fetish/cu/lib/getdate.y,v
 retrieving revision 1.99
 diff -p -u -r1.99 getdate.y
 --- lib/getdate.y 14 May 2005 07:58:06 -  1.99
 +++ lib/getdate.y 21 Jul 2005 21:55:40 -
 @@ -137,6 +137,25 @@ enum { MERam, MERpm, MER24 };
  
  enum { BILLION = 10, LOG10_BILLION = 9 };
  
 +/* Relative times.  */
 +typedef struct
 +{
 +  /* Relative year, month, day, hour, minutes, seconds, and nanoseconds.  */
 +  long int year;
 +  long int month;
 +  long int day;
 +  long int hour;
 +  long int minutes;
 +  long int seconds;
 +  long int ns;
 +} relative_time;
 +
 +#if HAVE_COMPOUND_LITERALS
 +# define RELATIVE_TIME_0 ((relative_time) { 0, 0, 0, 0, 0, 0, 0 })
 +#else
 +static relative_time const RELATIVE_TIME_0;
 +#endif
 +
  /* Information passed to and from the parser.  */
  typedef struct
  {
 @@ -167,13 +186,7 @@ typedef struct
struct timespec seconds; /* includes nanoseconds */
  
/* Relative year, month, day, hour, minutes, seconds, and nanoseconds.  */
 -  long int rel_year;
 -  long int rel_month;
 -  long int rel_day;
 -  long int rel_hour;
 -  long int rel_minutes;
 -  long int rel_seconds;
 -  long int rel_ns;
 +  relative_time rel;
  
/* Presence or counts of nonterminals of various flavors parsed so far.  */
bool timespec_seen;
 @@ -210,13 +223,16 @@ static long int time_zone_hhmm (textint,
long int intval;
textint textintval;
struct timespec timespec;
 +  relative_time rel;
  }
  
  %token tAGO tDST
  
 -%token intval tDAY tDAY_UNIT tDAYZONE tHOUR_UNIT tLOCAL_ZONE tMERIDIAN
 -%token intval tMINUTE_UNIT tMONTH tMONTH_UNIT tORDINAL
 -%token intval tSEC_UNIT tYEAR_UNIT tZONE
 +%token tYEAR_UNIT tMONTH_UNIT tHOUR_UNIT tMINUTE_UNIT tSEC_UNIT
 +%token intval tDAY_UNIT
 +
 +%token intval tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN
 +%token intval tMONTH tORDINAL tZONE
  
  %token textintval tSNUMBER tUNUMBER
  %token timespec tSDECIMAL_NUMBER tUDECIMAL_NUMBER
 @@ -224,6 +240,8 @@ static long int time_zone_hhmm (textint,
  %type intval o_colon_minutes o_merid
  %type timespec seconds signed_seconds unsigned_seconds
  
 +%type rel relunit relunit_snumber
 +
  %%
  
  spec:
 @@ -322,7 +340,15 @@ zone:
  tZONE
{ pc-time_zone = $1; }
| tZONE relunit_snumber
 -  { pc-time_zone = $1; pc-rels_seen = true; }
 +  { pc-time_zone = $1;
 + pc-rel.ns += $2.ns;
 + pc-rel.seconds += $2.seconds;
 + pc-rel.minutes += $2.minutes;
 + pc-rel.hour += $2.hour;
 + pc-rel.day += $2.day;
 + pc-rel.month += $2.month;
 + pc-rel.year += $2.year;
 +pc-rels_seen = true; }
| tZONE tSNUMBER o_colon_minutes
{ pc-time_zone = $1 + time_zone_hhmm ($2, $3); }
| tDAYZONE
 @@ -430,74 +456,83 @@ date:
  rel:
  relunit tAGO
{
 - pc-rel_ns = -pc-rel_ns;
 - pc-rel_seconds = -pc-rel_seconds;
 - pc-rel_minutes = -pc-rel_minutes;
 - pc-rel_hour = -pc-rel_hour;
 - pc-rel_day = -pc-rel_day;
 - pc-rel_month = -pc-rel_month;
 - pc-rel_year = -pc-rel_year;
 + pc-rel.ns -= $1.ns;
 + pc-rel.seconds -= $1.seconds;
 + pc-rel.minutes -= $1.minutes;
 + pc-rel.hour -= $1.hour;
 + pc-rel.day -= $1.day;
 + pc-rel.month -= $1.month;
 + pc-rel.year -= $1.year;
}
| relunit
 +  {
 + pc-rel.ns += $1.ns;
 + pc-rel.seconds += $1.seconds;
 + pc-rel.minutes += $1.minutes;
 + pc-rel.hour += $1.hour;
 + pc-rel.day += $1.day;
 + pc-rel.month += $1.month;
 + pc-rel.year += $1.year;
 +  }
;
  
  relunit:
  tORDINAL tYEAR_UNIT
 -  { pc-rel_year += $1 * $2; }
 +  { $$ = RELATIVE_TIME_0; $$.year = $1; }
| tUNUMBER tYEAR_UNIT
 -  { pc-rel_year += $1.value * $2; }
 +  { $$ = RELATIVE_TIME_0; $$.year = $1.value; }
| tYEAR_UNIT
 -  { pc-rel_year += $1; }
 +  { $$ = 

Re: bug in date(1)

[Paul Eggert]

John Adams [EMAIL PROTECTED] writes:

 Hello,
   I found some weird behavior in the date command version 5.2.1
 date --date=
displays Sat Apr  2 23:00:00 EST 2005
 while 
 date
displays 
 Sun Apr  3 09:56:08 EDT 2005

 Seems to be a bug.

Thanks for reporting that.  The empty string is supposed to stand for
the start of the current day -- that's in the documentation.  I
installed this patch, to both coreutils and gnulib.

2005-04-04  Paul Eggert  [EMAIL PROTECTED]

* lib/getdate.y (parser_control): rels_seen is now a boolean, not a
count, since there's no maximum.  All uses changed.
Add member dsts_seen.
(local_zone): Accumulate dsts_seen rather than relying on tm_isdst
not being INT_MAX.
(get_date): Initialize dsts_seen, and check that it doesn't go over 1.
Use pc_rels_seen to decide whther a date is absolute.

* lib/getdate.y (number): Don't overwrite year.
(get_date): Initialize pc.year.digits to 0, not 4, to enable above
check.

--- lib/getdate.y   21 Feb 2005 08:08:38 -  1.95
+++ lib/getdate.y   4 Apr 2005 19:47:42 -
@@ -175,12 +175,13 @@ typedef struct
   long int rel_seconds;
   long int rel_ns;
 
-  /* Counts of nonterminals of various flavors parsed so far.  */
+  /* Presence or counts of nonterminals of various flavors parsed so far.  */
   bool timespec_seen;
+  bool rels_seen;
   size_t dates_seen;
   size_t days_seen;
   size_t local_zones_seen;
-  size_t rels_seen;
+  size_t dsts_seen;
   size_t times_seen;
   size_t zones_seen;
 
@@ -255,7 +256,7 @@ item:
   | day
   { pc-days_seen++; }
   | rel
-  { pc-rels_seen++; }
+  { pc-rels_seen = true; }
   | number
   ;
 
@@ -306,9 +307,15 @@ time:
 
 local_zone:
 tLOCAL_ZONE
-  { pc-local_isdst = $1; }
+  {
+   pc-local_isdst = $1;
+   pc-dsts_seen += (0  $1);
+  }
   | tLOCAL_ZONE tDST
-  { pc-local_isdst = $1  0 ? 1 : $1 + 1; }
+  {
+   pc-local_isdst = 1;
+   pc-dsts_seen += (0  $1) + 1;
+  }
   ;
 
 zone:
@@ -504,7 +511,7 @@ unsigned_seconds:
 number:
 tUNUMBER
   {
-   if (pc-dates_seen
+   if (pc-dates_seen  ! pc-year.digits
 ! pc-rels_seen  (pc-times_seen || 2  $1.digits))
  pc-year = $1;
else
@@ -1179,7 +1186,7 @@ get_date (struct timespec *result, char 
   pc.input = p;
   pc.year.value = tmp-tm_year;
   pc.year.value += TM_YEAR_BASE;
-  pc.year.digits = 4;
+  pc.year.digits = 0;
   pc.month = tmp-tm_mon + 1;
   pc.day = tmp-tm_mday;
   pc.hour = tmp-tm_hour;
@@ -1197,11 +1204,12 @@ get_date (struct timespec *result, char 
   pc.rel_month = 0;
   pc.rel_year = 0;
   pc.timespec_seen = false;
+  pc.rels_seen = false;
   pc.dates_seen = 0;
   pc.days_seen = 0;
-  pc.rels_seen = 0;
   pc.times_seen = 0;
   pc.local_zones_seen = 0;
+  pc.dsts_seen = 0;
   pc.zones_seen = 0;
 
 #if HAVE_STRUCT_TM_TM_ZONE
@@ -1269,9 +1277,8 @@ get_date (struct timespec *result, char 
 *result = pc.seconds;
   else
 {
-  if (1  pc.times_seen || 1  pc.dates_seen || 1  pc.days_seen
- || 1  (pc.local_zones_seen + pc.zones_seen)
- || (pc.local_zones_seen  1  pc.local_isdst))
+  if (1  (pc.times_seen | pc.dates_seen | pc.days_seen | pc.dsts_seen
+  | (pc.local_zones_seen + pc.zones_seen)))
goto fail;
 
   tm.tm_year = to_year (pc.year) - TM_YEAR_BASE;
@@ -1292,7 +1299,7 @@ get_date (struct timespec *result, char 
}
 
   /* Let mktime deduce tm_isdst if we have an absolute time stamp.  */
-  if (pc.dates_seen | pc.days_seen | pc.times_seen)
+  if (!pc.rels_seen)
tm.tm_isdst = -1;
 
   /* But if the input explicitly specifies local time with or without


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date command

[Bauke Jan Douma]

On Fri, May 14, 2004 at 12:51:20AM +0200, Andreas Schwab wrote:
 duncan brown [EMAIL PROTECTED] writes:
 
  date +%C reports the 20th century, but we've been in the 21st since jan 01, 
  00:00:00
 
   %C   century (year divided by 100 and truncated to an integer) [00-99]

Surely this must be a Y2K-ism in the standard, no?

BJ


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date command

[Andreas Schwab]

Bauke Jan Douma [EMAIL PROTECTED] writes:

 On Fri, May 14, 2004 at 12:51:20AM +0200, Andreas Schwab wrote:
 duncan brown [EMAIL PROTECTED] writes:
 
  date +%C reports the 20th century, but we've been in the 21st since jan 01, 
  00:00:00
 
   %C   century (year divided by 100 and truncated to an integer) [00-99]

 Surely this must be a Y2K-ism in the standard, no?

Why?

$ date +%C%y
2004

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date command

[Bauke Jan Douma]

On Fri, May 14, 2004 at 11:27:53AM +0200, Andreas Schwab wrote:
 Bauke Jan Douma [EMAIL PROTECTED] writes:
 
  On Fri, May 14, 2004 at 12:51:20AM +0200, Andreas Schwab wrote:
  duncan brown [EMAIL PROTECTED] writes:
  
   date +%C reports the 20th century, but we've been in the 21st since jan 01, 
   00:00:00
  
%C   century (year divided by 100 and truncated to an integer) [00-99]
 
  Surely this must be a Y2K-ism in the standard, no?
 
 Why?
 
 $ date +%C%y
 2004

I am sorry, I answered under the assumption that you wrote
'truncated to the closest integer'.

Still, there is discrepancy in one common meaning of the word
'century' and the meaning it has here, as the original
poster noted.  Here it apparently means something like 'the
century part of the full year-number.'

BJ


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date command

[Andreas Schwab]

Bauke Jan Douma [EMAIL PROTECTED] writes:

 On Fri, May 14, 2004 at 11:27:53AM +0200, Andreas Schwab wrote:
 Bauke Jan Douma [EMAIL PROTECTED] writes:
 
  On Fri, May 14, 2004 at 12:51:20AM +0200, Andreas Schwab wrote:
  duncan brown [EMAIL PROTECTED] writes:
  
   date +%C reports the 20th century, but we've been in the 21st since jan 01, 
   00:00:00
  
%C   century (year divided by 100 and truncated to an integer) [00-99]
 
  Surely this must be a Y2K-ism in the standard, no?
 
 Why?
 
 $ date +%C%y
 2004

 I am sorry, I answered under the assumption that you wrote
 'truncated to the closest integer'.

 Still, there is discrepancy in one common meaning of the word
 'century' and the meaning it has here, as the original
 poster noted.  Here it apparently means something like 'the
 century part of the full year-number.'

The text is nearly identical to the one in the POSIX standard.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-coreutils