GNU bug report logs - #6897
date -d '1991-04-14 +1 day' fails

Previous Next

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

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

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

From: 李嘉鹏 <lijpbasin <at> 126.com>
To: bug-coreutils <at> gnu.org
Subject: date -d '1991-04-14 +1 day' fails
Date: Sun, 22 Aug 2010 11:04:44 +0800 (CST)

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

Hi,
I used some script(At the end of the letter) to get a series of date. but the script always fails at the date 1991-04-14. so I tested the single command
    date -d '1991-04-14 +1 day'
It would also fail with a error message
    date: invalid date `1991-04-14 +1 day'
displayed.
 
Here's some infomation about my platform:
jpli <at> databank:~> env
MKLROOT=/home/jpli/software/intel/Compiler/11.1/072/mkl
LESSKEY=/etc/lesskey.bin
NNTPSERVER=news
INFODIR=/usr/local/info:/usr/share/info:/usr/info
MANPATH=/home/jpli/software/ncview-1.93g/man:/home/jpli/software/intel/Compiler/11.1/072/man/en_US:/home/jpli/software/intel/Compiler/11.1/072/mkl/man/en_US:/home/jpli/software/intel/Compiler/11.1/072/man/en_US:/home/jpli/software/intel/Compiler/11.1/072/mkl/man/en_US:/software/pgi/linux86-64/7.1/mpi/mpich/man:/software/pgi/linux86-64/7.1/man:/usr/lib64/mpi/gcc/openmpi/share/man:/usr/local/man:/usr/local/share/man:/usr/share/man
HOSTNAME=databank
XKEYSYMDB=/usr/share/X11/XKeysymDB
INTEL_LICENSE_FILE=/home/jpli/software/intel/Compiler/11.1/072/licenses:/opt/intel/licenses:/home/jpli/intel/licenses:/home/jpli/software/intel/Compiler/11.1/072/licenses:/opt/intel/licenses:/home/jpli/intel/licenses
NCARG_INCLUDE=/software/ncarg-pgi/include
HOST=databank
TERM=xterm
SHELL=/bin/bash
PROFILEREAD=true
HISTSIZE=1000
SSH_CLIENT=172.16.102.36 54010 22
LIBRARY_PATH=/home/jpli/software/intel/Compiler/11.1/072/lib/intel64:/home/jpli/software/intel/Compiler/11.1/072/mkl/lib/em64t:/home/jpli/software/intel/Compiler/11.1/072/lib/intel64:/home/jpli/software/intel/Compiler/11.1/072/mkl/lib/em64t
FPATH=/home/jpli/software/intel/Compiler/11.1/072/mkl/include:/home/jpli/software/intel/Compiler/11.1/072/mkl/include
MORE=-sl
QTDIR=/usr/lib/qt3
SSH_TTY=/dev/pts/2
JRE_HOME=/usr/lib64/jvm/jre
USER=jpli
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.zip=00;31:*.zoo=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.avi=01;35:*.bmp=01;35:*.fli=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mng=01;35:*.mov=01;35:*.mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.tga=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.dl=01;35:*.gl=01;35:*.wmv=01;35:*.aiff=00;32:*.au=00;32:*.mid=00;32:*.mp3=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32:
LD_LIBRARY_PATH=/home/jpli/software/intel/impi/3.2.0.011/lib64:/home/jpli/software/intel/Compiler/11.1/072/lib/intel64:/home/jpli/software/intel/Compiler/11.1/072/mkl/lib/em64t:/home/jpli/software/intel/Compiler/11.1/072/lib/intel64:/home/jpli/software/intel/Compiler/11.1/072/mkl/lib/em64t:/usr/lib64/mpi/gcc/openmpi/lib64
XNLSPATH=/usr/share/X11/nls
NCARG_BIN=/software/ncarg-pgi/bin
ENV=/etc/bash.bashrc
CPATH=/home/jpli/software/intel/Compiler/11.1/072/mkl/include:/home/jpli/software/intel/Compiler/11.1/072/mkl/include
HOSTTYPE=x86_64
GASCRP=/software/grads/lib
FROM_HEADER=
PAGER=less
CSHEDIT=emacs
XDG_CONFIG_DIRS=/etc/xdg
NLSPATH=/home/jpli/software/intel/Compiler/11.1/072/lib/intel64/locale/%l_%t/%N:/home/jpli/software/intel/Compiler/11.1/072/mkl/lib/em64t/locale/%l_%t/%N:/home/jpli/software/intel/Compiler/11.1/072/idb/intel64/locale/%l_%t/%N:/home/jpli/software/intel/Compiler/11.1/072/lib/intel64/locale/%l_%t/%N:/home/jpli/software/intel/Compiler/11.1/072/mkl/lib/em64t/locale/%l_%t/%N:/home/jpli/software/intel/Compiler/11.1/072/idb/intel64/locale/%l_%t/%N
PGI=/software/pgi
MINICOM=-c on
MAIL=/var/mail/jpli
PATH=/home/jpli/bin:/software/matlab/R2009b/bin/:/software/R/bin:/software/grads/bin:/home/jpli/software/netcdf-intel/bin:/software/ncarg-pgi/bin:/home/jpli/software/intel/impi/3.2.0.011/bin64:/home/jpli/software/intel/Compiler/11.1/072/bin/intel64:/home/jpli/software/intel/Compiler/11.1/072/bin/intel64:/software/pgi/linux86-64/7.1-6/bin:/software/pgi/linux86-64/7.1/mpi/mpich/bin:/usr/lib64/mpi/gcc/openmpi/bin:/home/jpli/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib64/jvm/jre/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/home/jpli/software/ncview-1.93g/bin:.:/data4/jpli/rsm/libs_single/etc
CPU=x86_64
JAVA_BINDIR=/usr/lib64/jvm/jre/bin
INPUTRC=/home/jpli/.inputrc
PWD=/home/jpli
NCARG_ROOT=/software/ncarg-pgi
JAVA_HOME=/usr/lib64/jvm/jre
NCARG=/software/ncarg-pgi
LANG=en_US.UTF-8
PYTHONSTARTUP=/etc/pythonstart
PGRSH=ssh
NCARG_LIB=/software/ncarg-pgi/lib
QT_SYSTEM_DIR=/usr/share/desktop-data
SHLVL=1
HOME=/home/jpli
LESS_ADVANCED_PREPROCESSOR=no
OSTYPE=linux
LS_OPTIONS=-N --color=tty -T 0
WINDOWMANAGER=/usr/bin/kde
NETCDF=/home/jpli/software/netcdf-intel
G_FILENAME_ENCODING=@locale,UTF-8,ISO-8859-15,CP1252
LESS=-M -I
MACHTYPE=x86_64-suse-linux
LOGNAME=jpli
CVS_RSH=ssh
GADDIR=/software/grads/dat
XDG_DATA_DIRS=/usr/share:/etc/opt/kde3/share:/opt/gnome/share:/opt/kde3/share
SSH_CONNECTION=172.16.102.36 54010 192.168.0.101 22
LESSOPEN=lessopen.sh %s
INFOPATH=/usr/local/info:/usr/share/info:/usr/info
DISPLAY=localhost:12.0
INCLUDE=/home/jpli/software/intel/Compiler/11.1/072/mkl/include:/home/jpli/software/intel/Compiler/11.1/072/mkl/include
XAUTHLOCALHOSTNAME=databank
LESSCLOSE=lessclose.sh %s %s
G_BROKEN_FILENAMES=1
I_MPI_ROOT=/home/jpli/software/intel/impi/3.2.0.011
JAVA_ROOT=/usr/lib64/jvm/jre
COLORTERM=1
mc=() {  . /usr/share/mc/bin/mc-wrapper.sh
}
OLDPWD=/home/jpli/coreutils-8.5/man
_=/usr/bin/env
jpli <at> databank:~> uname -a
Linux databank 2.6.27.7-9-default #1 SMP 2008-12-04 18:10:04 +0100 x86_64 x86_64 x86_64 GNU/Linux
jpli <at> databank:~> date --version
date (GNU coreutils) 6.12
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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.
jpli <at> databank:~> lsb_release -a
LSB Version: core-2.0-noarch:core-3.2-noarch:core-2.0-x86_64:core-3.2-x86_64:desktop-3.2-amd64:desktop-3.2-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch
Distributor ID: SUSE LINUX
Description: openSUSE 11.1 (x86_64)
Release: 11.1
Codename: n/a

I've tried other machines with a different operating system(RHEL), and the core-utils versions at these systems differ(5.97, 5.2.1), The newest version of gnu core-utils was downloaded and compiled on the SUSE machine I use.
Whatever means I try, the same problem appear. So I assumed this to be a bug.

I'm from china by the way, and the time zone I am in and to which the systems were set is GMT8(or CST, China Standard Time).
 
Would you please check over the problem.
 I've not looked at any "Known Bugs" list because I didn't find one. If the problem happens to appear on the list.Would you please send me one.

The Script:
#!/bin/bash
st_year="1991"
st_month="04"
st_day="15"
ed_year="1991"
ed_month="09"
ed_day="01"
ed_date=$ed_year$ed_month$ed_day
year=$st_year
month=$st_month
day=$st_day
while true
do
    cur_date="$year$month$day"
    echo $cur_date
    if [ "$cur_date" = "$ed_date" ]
    then
        break
    fi
    nex_date=$(date +%Y%m%d -d "$year-$month-$day +1 day")
    year=$(echo $nex_date | cut -c1-4)
    month=$(echo $nex_date | cut -c5-6)
    day=$(echo $nex_date | cut -c7-8)
done
--

Jiapeng Li(lijpbasin <at> 126.com)
 
Dpeartment of Atmospheric Sciences
Nanjing University
Hankou Road 22
Nanjing, Jiangsu, China



您想拥有和网易免费邮箱一样强大的软件吗？

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

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

From: Bob Proulx <bob <at> proulx.com>
To: 李嘉鹏 <lijpbasin <at> 126.com>
Cc: 6897 <at> debbugs.gnu.org
Subject: Re: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Sun, 22 Aug 2010 18:12:45 -0600

李嘉鹏 wrote:

> I used some script(At the end of the letter) to get a series of
> date. but the script always fails at the date 1991-04-14. so I
> tested the single command
>     date -d '1991-04-14 +1 day'
> It would also fail with a error message
>     date: invalid date `1991-04-14 +1 day'
> displayed.

Thank you for the bug report.  However I am unable to reproduce it.
Therefore I conclude that the problem must be related to your
timezone.  Because you are taking dates a midnight I am guessing that
there is very likely a daylight savings time issue there.  (Was
Daylight Savings Time active then?)  Instead, try looking at dates at
noon.

  date -d '1991-04-14 12:00 +1 day'

> I'm from china by the way, and the time zone I am in and to which
> the systems were set is GMT8(or CST, China Standard Time).

I am sorry that I am not familiar with those timezones.  What is the
time there that would allow me to recreated it on my system?  Either
for a TZ variable setting or a setting for /etc/localtime?  For
example either TZ=Americas/Denver or TZ=US/Mountain would configure my
personal timezone.

>  I've not looked at any "Known Bugs" list because I didn't find
>  one. If the problem happens to appear on the list.Would you please
>  send me one.

Please review the FAQ for date.

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

Bob

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

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: 6897 <at> debbugs.gnu.org
Cc: 李嘉鹏 <lijpbasin <at> 126.com>
Subject: Re: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Sun, 22 Aug 2010 20:09:55 -0500 (GMT+5)

Bob Proulx writes:
>   date -d '1991-04-14 12:00 +1 day'
> 
> > I'm from china by the way, and the time zone I am in and to which
> > the systems were set is GMT8(or CST, China Standard Time).

Indeed, 

  TZ=Asia/Shanghai date -d '4/14/1991'
  date: invalid date `4/14/1991'
  TZ=Asia/Shanghai date -d '4/14/1991 01:00:00'
  Sun Apr 14 01:00:00 CDT 1991
  TZ=Asia/Shanghai date -d '1/1/1970 GMT + 671558399 sec'
  Sat Apr 13 23:59:59 CST 1991
  TZ=Asia/Shanghai date -d '1/1/1970 GMT + 671558400 sec'
  Sun Apr 14 01:00:00 CDT 1991

According to tzdata, China had DST from 1986 to 1991.

This comment in the source file indicates some doubt about correctness:

# From Paul Eggert (2006-03-22):
# Shanks & Pottenger write that China (except for Hong Kong and Macau)
# has had a single time zone since 1980 May 1, observing summer DST
# from 1986 through 1991; this contradicts Devine's
# note about Time magazine, though apparently _something_ happened in 1986.
# Go with Shanks & Pottenger for now.  I made up names for the other
# pre-1980 time zones.

Maybe someone who can read Chinese could clear it up by finding the original
policy declarations...

> Please review the FAQ for date.
> 
>   http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-work=
> ing-right_002e

There might be less occurrences of this misunderstanding if we could teach
date that -d 4/14/1991 is not actually a request for 4/14/1991 00:00:00, but
"any time that existed during the day 4/14/1991", or perhaps a more specific
"the first second of 4/14/1991".

Has that been considered and rejected already, or is it just waiting for
someone to implement it?

Message #16 received at 6897-done <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: 李嘉鹏 <lijpbasin <at> 126.com>
Cc: 6897-done <at> debbugs.gnu.org
Subject: Re: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Mon, 23 Aug 2010 02:48:43 -0600

Bob Proulx wrote:
> 李嘉鹏 wrote:
> > I used some script(At the end of the letter) to get a series of
> > date. but the script always fails at the date 1991-04-14. so I
> > tested the single command
> >     date -d '1991-04-14 +1 day'
> > It would also fail with a error message
> >     date: invalid date `1991-04-14 +1 day'
> > displayed.
> 
> Thank you for the bug report.  However I am unable to reproduce it.
> Therefore I conclude that the problem must be related to your
> timezone.  Because you are taking dates a midnight I am guessing that
> there is very likely a daylight savings time issue there.  (Was
> Daylight Savings Time active then?)  Instead, try looking at dates at
> noon.
> 
>   date -d '1991-04-14 12:00 +1 day'

Using Asia/Chongqing timezone shows that DST was active at that time.

  $ zdump -v Asia/Chongqing | grep 1991
  Asia/Chongqing  Sat Apr 13 15:59:59 1991 UTC = Sat Apr 13 23:59:59 1991 CST isdst=0 gmtoff=28800
  Asia/Chongqing  Sat Apr 13 16:00:00 1991 UTC = Sun Apr 14 01:00:00 1991 CDT isdst=1 gmtoff=32400
  Asia/Chongqing  Sat Sep 14 14:59:59 1991 UTC = Sat Sep 14 23:59:59 1991 CDT isdst=1 gmtoff=32400
  Asia/Chongqing  Sat Sep 14 15:00:00 1991 UTC = Sat Sep 14 23:00:00 1991 CST isdst=0 gmtoff=28800

There was no 1991-04-14 00:00:00 since the time progressed to Apr 14
01:00:00 with the next clock tick.  Because 1991-04-14 00:00:00 does
not exist 'date' returns an invalid date error for it.

Using the time at noon would avoid these problems.  Also using time in
UTC avoids all daylight savings time issues.

Bob

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

From: Jim Meyering <jim <at> meyering.net>
To: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
Cc: 6897 <at> debbugs.gnu.org, 李嘉鹏 <lijpbasin <at> 126.com>
Subject: Re: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Mon, 23 Aug 2010 15:40:43 +0200

Alan Curry wrote:
...
> There might be less occurrences of this misunderstanding if we could teach
> date that -d 4/14/1991 is not actually a request for 4/14/1991 00:00:00, but
> "any time that existed during the day 4/14/1991", or perhaps a more specific
> "the first second of 4/14/1991".

Use the 12th hour of the day, "1991-4-14 12:00".
I suspect that there have been very few DST transitions
around midday.

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

From: Paul Eggert <eggert <at> CS.UCLA.EDU>
To: Alan Curry <pacman-cu <at> kosh.dhis.org>
Cc: 6897 <at> debbugs.gnu.org, 李嘉鹏 <lijpbasin <at> 126.com>
Subject: Re: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Mon, 23 Aug 2010 09:01:39 -0700

On 08/22/10 18:09, Alan Curry wrote:
> There might be less occurrences of this misunderstanding if we could teach
> date that -d 4/14/1991 is not actually a request for 4/14/1991 00:00:00, but
> "any time that existed during the day 4/14/1991", or perhaps a more specific
> "the first second of 4/14/1991".
> 
> Has that been considered and rejected already, or is it just waiting for
> someone to implement it?

As far as I know nobody has ever suggested that, and it is a reasonable suggestion.
However, it would not fix the problem in general, since in some cases there
is no "first second of date X", even when X is valid.  For example:

$ TZ=Pacific/Kwajalein date -d 1993-08-20
date: invalid date `1993-08-20'

There was no time during the day 1993-08-20, because at midnight Kwajalein
moved the clocks ahead by 24 hours.

Perhaps the semantics could be "the first second whose time stamp is on
or after 1993-08-20 00:00:00", though then we'd have to deal with bug reports
from people on Kwajalein saying "wait a minute: I asked for August 20, but
it gave me August 21!".

Aren't dates fun?

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

From: "Alan Curry" <pacman-cu <at> kosh.dhis.org>
To: eggert <at> CS.UCLA.EDU (Paul Eggert)
Cc: 6897 <at> debbugs.gnu.org
Subject: Re: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Mon, 23 Aug 2010 16:59:56 -0500 (GMT+5)

Paul Eggert writes:
> 
> On 08/22/10 18:09, Alan Curry wrote:
> > There might be less occurrences of this misunderstanding if we could teach
> > date that -d 4/14/1991 is not actually a request for 4/14/1991 00:00:00, but
> > "any time that existed during the day 4/14/1991", or perhaps a more specific
> > "the first second of 4/14/1991".
> > 
> > Has that been considered and rejected already, or is it just waiting for
> > someone to implement it?
> 
> As far as I know nobody has ever suggested that, and it is a reasonable suggestion.
> However, it would not fix the problem in general, since in some cases there
> is no "first second of date X", even when X is valid.  For example:
> 
> $ TZ=Pacific/Kwajalein date -d 1993-08-20
> date: invalid date `1993-08-20'

There's nothing wrong with that error message. It's telling the truth about
1993-08-28 being an invalid date.

But TZ=Asia/Shanghai date -d '4/14/1991' says:
date: invalid date `4/14/1991'

which is a lie. 4/14/1991 is not an invalid date. It made a bad assumption
(that midnight was intended, when the user didn't ask for midnight at all)
and then reported an error caused by the bad assumption, and didn't even have
the courtesy to mention the assumption.

Bonus thought: the "date" command is misnamed. If it actually worked with
dates, it wouldn't need to attach an hour, minute, and second to everything.
It would understand 4/14/1991 as representing an entire day, and "+ 1 day"
added to it would represent the entire next day. But date doesn't work with
dates, it works with time_t's. This is not obvious to the casual user.

-- 
Alan Curry

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Alan Curry <pacman-cu <at> kosh.dhis.org>
Cc: 6897 <at> debbugs.gnu.org
Subject: Re: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Mon, 23 Aug 2010 15:26:05 -0700

On 08/23/2010 02:59 PM, Alan Curry wrote:
> date: invalid date `4/14/1991'
>
> which is a lie. 4/14/1991 is not an invalid date.

It is an invalid date, under the assumption
that dates without times refer to the time 00:00:00
on that date.  This assumption has been in the software
for ages, and explains, for example, why
"date -d '2010-01-01 25 hours'" reports 01:00 the
next day.  No doubt this could all be better documented,
but there's nothing unreasonable per se about the
assumption.

> Bonus thought: the "date" command is misnamed.

"time" was taken.  At this late date (:-) it's not
likely that the names will be changed.

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

From: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
To: Paul Eggert <eggert <at> CS.UCLA.EDU>, Alan Curry <pacman-cu <at> kosh.dhis.org>
Cc: "6897 <at> debbugs.gnu.org" <6897 <at> debbugs.gnu.org>,
	李嘉鹏 <lijpbasin <at> 126.com>
Subject: RE: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Tue, 24 Aug 2010 09:23:15 +0200

On 08/23/2010 18:02, Payk Eggert wrote:

> ... For example:
> $ TZ=Pacific/Kwajalein date -d 1993-08-20
> date: invalid date `1993-08-20'

> There was no time during the day 1993-08-20, because at midnight Kwajalein
> moved the clocks ahead by 24 hours.

BTW: This example looks different here:

  $ TZ=Pacific/Kwajalein date -d 1993-08-20
  Sat Aug 21 00:00:00 MHT 1993

  $ date --version
  date (GNU coreutils) 8.5
  Packaged by Cygwin (8.5-2)
  Copyright (C) 2010 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
  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.

Why?

> Aren't dates fun?

Well, imagine such [an ugly but easy] loop thru all days of a year:

  d='1993-01-01'
  while [ "${d%%-*}" = "1993" ]
  do
    echo $d                                   # loop body
    d=$( date -d "$d + 1 day" '+%Y-%m-%d' )   # step to next day
  done

Given that there's no valid time like 12:00 with TZ="Pacific/Kwajalein" for Aug 20th,
do you think this loop should really fail?
With a normal user's perspective, I'd expect `date` to "just do the job"
and find the next day after 1993-08-19 ...

Have a nice day,
Berny

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

From: Paul Eggert <eggert <at> CS.UCLA.EDU>
To: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Cc: "6897 <at> debbugs.gnu.org" <6897 <at> debbugs.gnu.org>,
	Alan Curry <pacman-cu <at> kosh.dhis.org>,
	李嘉鹏 <lijpbasin <at> 126.com>
Subject: Re: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Tue, 24 Aug 2010 01:03:56 -0700

On 08/24/10 00:23, Voelker, Bernhard wrote:

> BTW: This example looks different here:
> 
>   $ TZ=Pacific/Kwajalein date -d 1993-08-20
>   Sat Aug 21 00:00:00 MHT 1993
> 
>   $ date --version
>   date (GNU coreutils) 8.5
>   Packaged by Cygwin (8.5-2)
>   ...
> 
> Why?

Haven't a clue.  Perhaps you can debug it?  I get the
correct answer (i.e., there was no such date) on both
RHEL 5 with my own-built coreutils 8.5, and with
Ubuntu 10.04 with its standard-issue coreutils 7.4.

> With a normal user's perspective, I'd expect `date` to "just do the job"

Gee, I don't know, all the normal users I know
just want "date" to print the date.

Date arithmetic is pretty esoteric, after all.
What is one month after 31 January, for example?
There's no way this stuff can be done in a way
that is straightforward and satisfies everybody.
I'm becoming more inclined to say that GNU date
shouldn't be doing date arithmetic at all.

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

From: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
To: Paul Eggert <eggert <at> CS.UCLA.EDU>
Cc: "6897 <at> debbugs.gnu.org" <6897 <at> debbugs.gnu.org>,
	Alan Curry <pacman-cu <at> kosh.dhis.org>,
	李嘉鹏 <lijpbasin <at> 126.com>
Subject: RE: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Tue, 24 Aug 2010 11:22:24 +0200

On 08/24/10 10:04, Eggert, Paul wrote:

> On 08/24/10 00:23, Voelker, Bernhard wrote:
>
>> BTW: This example looks different here:
>> 
>>   $ TZ=Pacific/Kwajalein date -d 1993-08-20
>>   Sat Aug 21 00:00:00 MHT 1993
>> 
>>   $ date --version
>>   date (GNU coreutils) 8.5
>>   Packaged by Cygwin (8.5-2)
>>   ...
>> 
>> Why?
>
> Haven't a clue.  Perhaps you can debug it?  I get the
> correct answer (i.e., there was no such date) on both
> RHEL 5 with my own-built coreutils 8.5, and with
> Ubuntu 10.04 with its standard-issue coreutils 7.4.

Unfortunately, I'm currently quite busy.
I've sent a report to cygwin <at> cygwin.com:
http://cygwin.com/ml/cygwin/2010-08/msg00745.html


> Date arithmetic is pretty esoteric, after all.
> What is one month after 31 January, for example?

yes, sometimes it's not too important to care
about tomorrow ... but sometimes it is ;-)

> I'm becoming more inclined to say that GNU date
> shouldn't be doing date arithmetic at all.

I think it should - the point is that the base for
such date arithmetic must be valid. And since 1991-04-14
is a valid date in the OPs timezone, date should IMO
return the 15th for "1991-04-14 +1 day" - as Alan wrote.

Have a nice day,
Berny

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

From: Eric Blake <eblake <at> redhat.com>
To: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
Cc: Paul Eggert <eggert <at> CS.UCLA.EDU>,
	"6897 <at> debbugs.gnu.org" <6897 <at> debbugs.gnu.org>,
	Alan Curry <pacman-cu <at> kosh.dhis.org>,
	李嘉鹏 <lijpbasin <at> 126.com>
Subject: Re: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Tue, 24 Aug 2010 07:08:40 -0600

On 08/24/2010 01:23 AM, Voelker, Bernhard wrote:
>    $ TZ=Pacific/Kwajalein date -d 1993-08-20
>    Sat Aug 21 00:00:00 MHT 1993
> 
>    $ date --version
>    date (GNU coreutils) 8.5
>    Packaged by Cygwin (8.5-2)
> Why?

Most likely, because cygwin is using a slightly different tzdata package
than Linux.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

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

From: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Paul Eggert <eggert <at> CS.UCLA.EDU>,
	"6897 <at> debbugs.gnu.org" <6897 <at> debbugs.gnu.org>,
	Alan Curry <pacman-cu <at> kosh.dhis.org>,
	李嘉鹏 <lijpbasin <at> 126.com>
Subject: RE: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Tue, 24 Aug 2010 15:31:54 +0200

On 08/24/2010 15:09, Eric Blake wrote:

> On 08/24/2010 01:23 AM, Voelker, Bernhard wrote:
>>    $ TZ=Pacific/Kwajalein date -d 1993-08-20
>>    Sat Aug 21 00:00:00 MHT 1993
>> 
>>    $ date --version
>>    date (GNU coreutils) 8.5
>>    Packaged by Cygwin (8.5-2)
>> Why?
>
>Most likely, because cygwin is using a slightly different tzdata package
>than Linux.

SLES-10.3> /usr/sbin/zdump -v /usr/share/zoneinfo/Pacific/Kwajalein
/usr/share/zoneinfo/Pacific/Kwajalein  -9223372036854775808 = NULL
/usr/share/zoneinfo/Pacific/Kwajalein  -9223372036854689408 = NULL
/usr/share/zoneinfo/Pacific/Kwajalein  Mon Dec 31 12:50:39 1900 UTC = Mon Dec 31 23:59:59 1900 LMT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Mon Dec 31 12:50:40 1900 UTC = Mon Dec 31 23:50:40 1900 MHT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Tue Sep 30 12:59:59 1969 UTC = Tue Sep 30 23:59:59 1969 MHT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Tue Sep 30 13:00:00 1969 UTC = Tue Sep 30 01:00:00 1969 KWAT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Fri Aug 20 11:59:59 1993 UTC = Thu Aug 19 23:59:59 1993 KWAT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Fri Aug 20 12:00:00 1993 UTC = Sat Aug 21 00:00:00 1993 MHT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  9223372036854689407 = NULL
/usr/share/zoneinfo/Pacific/Kwajalein  9223372036854775807 = NULL

Cygwin> /usr/sbin/zdump -v /usr/share/zoneinfo/Pacific/Kwajalein
/usr/share/zoneinfo/Pacific/Kwajalein  Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 07:45:52 1901 MHT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 07:45:52 1901 MHT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Tue Sep 30 12:59:59 1969 UTC = Tue Sep 30 23:59:59 1969 MHT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Tue Sep 30 13:00:00 1969 UTC = Tue Sep 30 01:00:00 1969 KWAT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Fri Aug 20 11:59:59 1993 UTC = Thu Aug 19 23:59:59 1993 KWAT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Fri Aug 20 12:00:00 1993 UTC = Sat Aug 21 00:00:00 1993 MHT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 15:14:07 2038 MHT isdst=0
/usr/share/zoneinfo/Pacific/Kwajalein  Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 15:14:07 2038 MHT isdst=0

Looks pretty much the same to me for the 1993 entries ...

Have a nice day,
Berny

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

From: Bob Proulx <bob <at> proulx.com>
To: 6897 <at> debbugs.gnu.org
Subject: Re: bug#6897: date -d '1991-04-14 +1 day' fails
Date: Tue, 24 Aug 2010 16:24:48 -0600

Paul Eggert wrote:
> Voelker, Bernhard wrote:
> > With a normal user's perspective, I'd expect `date` to "just do the job"
> 
> Gee, I don't know, all the normal users I know
> just want "date" to print the date.
> 
> Date arithmetic is pretty esoteric, after all.
> What is one month after 31 January, for example?
> There's no way this stuff can be done in a way
> that is straightforward and satisfies everybody.

Months (moonths?) are terrible.  An astronomical event that isn't
synchronized to anything human but forced to fit in irregular ways.
It isn't possible to have a regular answer that is consistent and
correct.

(I want to say that any calculation based upon months has no hope of
being correct.  It would be better to use 30 days or 4 weeks or other
such more precise figure.  But then we would degrade into a long
discussion about doing such things and looking at any appointment
calendar and the large number of "third Tuesday after the first Monday
in June" types of rules will show how hard it is to cover everything
needed.  Just try calculating the date of Easter for example.)

> I'm becoming more inclined to say that GNU date
> shouldn't be doing date arithmetic at all.

It does seem an odd thing to have in there.  One of the many feature
creeps that would probably have been nicer in a separate program.  It
would be great to have a general purpose calendar date and time
manipulation program.  For example, while it is nice to be able to
say "next Thursday" and have that work it would also be nice to ask
how many days (or how many weeks) exist between two dates and get an
answer directly.  In hindsight it seems better to use a separate
program for the calculation and then feed that answer to date for
setting the clock.

Bob

Previous Next

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