bug in date

[Klaus Umbach]

Hi,
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.

$ date
Wed Jul 20 20:34:25 CEST 2005
$ date --date="tomorrow 1 hour ago"
Tue Jul 19 19:34:09 CEST 2005
$ date --date="yesterday 1 hour ago" 
Thu Jul 21 19:34:13 CEST 2005
$ date --date="1 hour ago tomorrow" 
Thu Jul 21 19:34:17 CEST 2005

regards
Klaus Umbach



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

Bug in date?

[Enrique Arizón Benito]

|If I try to exec:

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

but

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

doesn't work.

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

||Is that the expected behaviour?

More info:

 #date --version
 date (GNU coretutils) 6.10-6

 #echo $LC_ALL
 C
 #echo $LANG
 C


Regards,

Enrique
|||


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

Bug in 'date'

[Sergey Trubnikov]

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

Thanks for attention.

P.S. Sorry for my english :)
-- 
BuG
Sergey Trubnikov
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

bug in date

[Emily Lane]

I seem to have come across an anomaly in the date function.  It only seems to 
happen for April 5th
e.g.
> date --date "20090405 24 hour" +%d
05
> date --date "20090405 24 hour" +%m
04

For any other day this correctly adds 24 hours to the date.

Thanks

EMily

Dr Emily Lane
NIWA
Taihoro Nukurangi
P.O. Box 8602, Riccarton
Christchurch, New Zealand 8440
Phone: +64 3 343-7856
Email: e.l...@niwa.co.nz

NIWA is the trading name of the National Institute of Water & Atmospheric 
Research Ltd.


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

bug in date command

[duncan brown]

date +%C reports the 20th century, but we've been in the 21st since jan 01, 00:00:00

-d

Time will end all my troubles, but I don't always approve of Time's methods.

+( duncan brown
+( [EMAIL PROTECTED]
+( http://www.linuxadvocate.net



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

bug in date(1)

[John Adams]

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.  Maybe a usage msg for the first instance

[EMAIL PROTECTED]


___
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  tDAY tDAY_UNIT tDAYZONE tHOUR_UNIT tLOCAL_ZONE tMERIDIAN
-%token  tMINUTE_UNIT tMONTH tMONTH_UNIT tORDINAL
-%token  tSEC_UNIT tYEAR_UNIT tZONE
+%token tYEAR_UNIT tMONTH_UNIT tHOUR_UNIT tMINUTE_UNIT tSEC_UNIT
+%token  tDAY_UNIT
+
+%token  tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN
+%token  tMONTH tORDINAL tZONE
 
 %token  tSNUMBER tUNUMBER
 %token  tSDECIMAL_NUMBER tUDECIMAL_NUMBER
@@ -224,6 +240,8 @@ static long int time_zone_hhmm (textint,
 %type  o_colon_minutes o_merid
 %type  seconds signed_seconds unsigned_seconds
 
+%type  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; }
   | tUNUMBE

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  tDAY tDAY_UNIT tDAYZONE tHOUR_UNIT tLOCAL_ZONE tMERIDIAN
> -%token  tMINUTE_UNIT tMONTH tMONTH_UNIT tORDINAL
> -%token  tSEC_UNIT tYEAR_UNIT tZONE
> +%token tYEAR_UNIT tMONTH_UNIT tHOUR_UNIT tMINUTE_UNIT tSEC_UNIT
> +%token  tDAY_UNIT
> +
> +%token  tDAY tDAYZONE tLOCAL_ZONE tMERIDIAN
> +%token  tMONTH tORDINAL tZONE
>  
>  %token  tSNUMBER tUNUMBER
>  %token  tSDECIMAL_NUMBER tUDECIMAL_NUMBER
> @@ -224,6 +240,8 @@ static long int time_zone_hhmm (textint,
>  %type  o_colon_minutes o_merid
>  %type  seconds signed_seconds unsigned_seconds
>  
> +%type  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 

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

Bug in date command

[Bob Kline]

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.

-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com



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

bug in date-command

[Bas Mijling]

Hi,

I use the date command to find the next day of a date written in the 
'mmdd' format,

e.g. for 25 October 2008

date -d "20081025 1 days" +%Y%m%d

which gives as result the next day: 20081026


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


If you manage to reproduce this behaviour at your system too there might 
be a bug in the `date` utility

Regards,

Bas Mijling


___
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 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

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Emily Lane on 7/9/2009 6:38 PM:
> I seem to have come across an anomaly in the date function.  It only seems to 
> happen for April 5th
> e.g.
>> date --date "20090405 24 hour" +%d
> 05
>> date --date "20090405 24 hour" +%m
> 04
> 
> For any other day this correctly adds 24 hours to the date.

Not a bug; you are running into daylight savings issues.  See the FAQ:
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

iEYEARECAAYFAkpWqrAACgkQ84KuGfSFAYAEYACeO9T/lRJBDNnBZ0SAQSld6Nr4
Dy0An2YGmIHNkzQ79g4e2nR2Xae6WqbV
=bY25
-END PGP SIGNATURE-


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

bug in date command

[Prog piR]

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

In addition, is there any option to have lowercase ?

Thanks

bug in date utillity

[Vladislav ZItikis]

Good evening

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

[EMAIL PROTECTED] date --version
date (GNU coreutils) 5.94
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.
[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'
Thank you

-- 
Vladislav Zitikis


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

Bug in date command

[Toni]

Linux version 2.6.22-14-generic ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929
(prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 SMP Sun Oct 14 23:05:12 GMT 2007

date +%R does not show seconds
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date command

[Andreas Schwab]

"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]

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 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

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

bug in date (coreutils-6.12)

[David Chin]

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.

To reproduce, do this:

 date -d "2006-04-02 02:30:00"

As a comparison, do this:

date -d "2006-04-01 02:30:00"

Cheers,
Dave

-- 
Email: david.w.h.chin AT gmail.com dwchin AT lroc.harvard.edu
http://gallatin.physics.lsa.umich.edu/~dwchin/Work
Public key: http://david.w.h.chin.googlepages.com/crypto.html
 pub 2048D/1D8A5BC2 2008-08-18 [expires: 2009-08-18]
 uid David Chin 
 uid David Chin 
 uid David Chin 
 Key fingerprint = A8A0 6E91 6A42 F42E BF18 2202 29C0 A056 1D8A 5BC2


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

Re: Bug in date command

[Eric Blake]

Bob Kline  rksystems.com> writes:

> 
> The date command reports the wrong ISO week number in some cases.  For
> example:
> 
> $ date -d 2008-12-31 +%Y%V
> 200801

Not a bug in date, but in your misuse of incompatible formats.  2008-12-31 is 
in the first ISO week of 2009, as evidenced by:

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

The ISO week starts on Monday, and is attributed to the year that contains four 
or more days of the week; it can be 01-53 inclusive (but 53 is rare).

Perhaps you wanted the more traditional week number:

$ date -d 2008-12-31 +%Y%U
200852
$ date -d 2009-01-01 +%Y%U
200900

Here, the week starts on Sunday, the range is 00-53, and no days are attributed 
to an adjacent year; week 01 is the first full week of the year.

This is specified by POSIX:
http://www.opengroup.org/onlinepubs/9699919799/utilities/date.html

In short, %G and %V go together, %Y and %U go together, and any other 
combination causes confusion.  Perhaps we should try to mention this in the 
usage text somehow?

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.

-- 
Eric Blake




___
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-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

[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.

bug#8648: bug in date?

[Turner, Neil]

Maybe found a bug in date...  the following command:

$ date --date="yesterday 00:00 +1 day"
Mon May  9 16:59:00 PDT 2011

The date as I type this is May 10th... so I was expecting the output to be:
Tues May  10 00:00:00 PDT 2011

Thanks,

Neil

bug#8648: bug in date?

[Ondrej Vasik]

On Tue, 2011-05-10 at 16:36 -0700, Turner, Neil wrote:
> Maybe found a bug in date...  the following command:
> 
> $ date --date="yesterday 00:00 +1 day"
> Mon May  9 16:59:00 PDT 2011
> 
> The date as I type this is May 10th... so I was expecting the output to be:
> Tues May  10 00:00:00 PDT 2011

First of all, please always report the version of coreutils where you
experience the unexpected behaviour.

However - it is a tricky thing - you are human, you know what you have
meant by +1 ... but flex getdate parser is not a human - and it simply
parses the date format. In this case date format expects +1 is timezone
(and because I see the offset of 1 minute, I think you have quite old
version of coreutils). +1 is then implicit for the relative time offset
(you may consider date --date="yesterday 00:00 +3 day" to be even more
"buggy"). Not too much to do, date parser is very fragile and you will
always have this kind of disambiguations there. So there is only one
hint, make the format as complete as possible (date time timezone
offset)...

With `date --date="yesterday 00:00 PDT +1 day"` you should get the date
you expected.

Greetings,
 Ondrej Vasik

bug#8648: bug in date?

[Jim Meyering]

tag 8648 + notabug
close 8648
thanks

Ondrej Vasik wrote:
> On Tue, 2011-05-10 at 16:36 -0700, Turner, Neil wrote:
>> Maybe found a bug in date...  the following command:
>>
>> $ date --date="yesterday 00:00 +1 day"
>> Mon May  9 16:59:00 PDT 2011
>>
>> The date as I type this is May 10th... so I was expecting the output to be:
>> Tues May  10 00:00:00 PDT 2011
>
> First of all, please always report the version of coreutils where you
> experience the unexpected behaviour.
>
> However - it is a tricky thing - you are human, you know what you have
> meant by +1 ... but flex getdate parser is not a human - and it simply
> parses the date format. In this case date format expects +1 is timezone
> (and because I see the offset of 1 minute, I think you have quite old
> version of coreutils). +1 is then implicit for the relative time offset
> (you may consider date --date="yesterday 00:00 +3 day" to be even more
> "buggy"). Not too much to do, date parser is very fragile and you will
> always have this kind of disambiguations there. So there is only one
> hint, make the format as complete as possible (date time timezone
> offset)...
>
> With `date --date="yesterday 00:00 PDT +1 day"` you should get the date
> you expected.

Thanks for the report, Neil, and for replying, Ondřej.

Neil, if you run "info date example", you'll see pretty many examples.
There are some here, too:
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

BTW, simply removing the "+" should make date do what you
want most of the time:

  $ date --date="yesterday 00:00 1 day"

However, that may well fail around DST changes (as explained
in detail via that FAQ), so you should use noon rather than midnight:

  $ date --date="yesterday 12:00 1 day"

P.S. I've closed this ticket but you're welcome to continue discussing
and even to reopen it if I've missed something.

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 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 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 (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 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

bug#8357: coreutils bug in date

[Heikki Orsila]

Hello, I found a case where GNU date works pretty oddly.
At 2011-03-27 Finland moved to 'summer time'. After midnight at 2011-03-28
our web site's cron script did (date -I -d yesterday) which yielded
unexpected results:

$ date
Mon Mar 28 00:36:07 EEST 2011
$ date -I -d yesterday
2011-03-26
$ date -I -d '24 hours ago'
2011-03-26

Our scripts produced bad results due to this "feature/bug". Maybe our fault, 
but this is definitely unexpected behaviour.

-- 
Heikki Orsila
heikki.ors...@iki.fi
http://www.iki.fi/shd

bug#8357: coreutils bug in date

[Bob Proulx]

tags 8357 + moreinfo notabug
thanks

Heikki Orsila wrote:
> Hello, I found a case where GNU date works pretty oddly.
> At 2011-03-27 Finland moved to 'summer time'. After midnight at 2011-03-28
> our web site's cron script did (date -I -d yesterday) which yielded
> unexpected results:
> 
> $ date
> Mon Mar 28 00:36:07 EEST 2011
> $ date -I -d yesterday
> 2011-03-26
> $ date -I -d '24 hours ago'
> 2011-03-26
> 
> Our scripts produced bad results due to this "feature/bug". Maybe our fault, 
> but this is definitely unexpected behaviour.

Thank you for your bug report.  However I this is not a bug in date
but a misunderstanding of how relative times and DST interact.

Note that 'date -I' is a deprecated option.  Please consider updating
the syntax.  In a future release -I may be removed.

First, let's understand when the time changes.

  $ zdump -v Europe/Helsinki | grep 2011
  Europe/Helsinki  Sun Mar 27 00:59:59 2011 UTC = Sun Mar 27 02:59:59 2011 EET 
isdst=0 gmtoff=7200
  Europe/Helsinki  Sun Mar 27 01:00:00 2011 UTC = Sun Mar 27 04:00:00 2011 EEST 
isdst=1 gmtoff=10800
  Europe/Helsinki  Sun Oct 30 00:59:59 2011 UTC = Sun Oct 30 03:59:59 2011 EEST 
isdst=1 gmtoff=10800
  Europe/Helsinki  Sun Oct 30 01:00:00 2011 UTC = Sun Oct 30 03:00:00 2011 EET 
isdst=0 gmtoff=7200

Sun Mar 27 02:59:59 2011 EET was the last second in EET and Sun Mar 27
04:00:00 2011 EEST was the very next second in your timezone.  There
is no 03:00:00 through 03:59:59.  The time skips (by law and politics)
directly to 04:00:00 in that timezone.  The day is defined to be one
hour shorter that day.

The documentation for date says:

 The unit of time displacement may be selected by the string `year'
  or `month' for moving by whole years or months.  These are fuzzy units,
  as years and months are not all of equal duration.  More precise units
  are `fortnight' which is worth 14 days, `week' worth 7 days, `day'
  worth 24 hours, `hour' worth 60 minutes, `minute' or `min' worth 60
  seconds, and `second' or `sec' worth one second.  An `s' suffix on
  these units is accepted and ignored.

 The string `tomorrow' is worth one day in the future (equivalent to
  `day'), the string `yesterday' is worth one day in the past (equivalent
  to `day ago').

So 'yesterday' or '24 hours ago' are equivalent.  These are exactly 24
hours ago or 86400 seconds.  This is a critical point in your problem.

  $ TZ=Europe/Helsinki date -d 'Mon Mar 28 00:36:07 EEST 2011'
  Mon Mar 28 00:36:07 EEST 2011

  $ TZ=Europe/Helsinki date -d 'Mon Mar 28 00:36:07 EEST 2011 24 hours ago'
  Sat Mar 26 23:36:07 EET 2011

This recreates the same results you posted.  The reasoning is a little
more obvious if I list out the hours explicitly.

  Mon Mar 28 00:36:07 EEST 2011   -0 hours
  Sun Mar 27 23:36:07 EEST 2011   -1 hours
  Sun Mar 27 22:36:07 EEST 2011   -2 hours
  Sun Mar 27 21:36:07 EEST 2011   -3 hours
  Sun Mar 27 20:36:07 EEST 2011   -4 hours
  Sun Mar 27 19:36:07 EEST 2011   -5 hours
  Sun Mar 27 18:36:07 EEST 2011   -6 hours
  Sun Mar 27 17:36:07 EEST 2011   -7 hours
  Sun Mar 27 16:36:07 EEST 2011   -8 hours
  Sun Mar 27 15:36:07 EEST 2011   -9 hours
  Sun Mar 27 14:36:07 EEST 2011  -10 hours
  Sun Mar 27 13:36:07 EEST 2011  -11 hours
  Sun Mar 27 12:36:07 EEST 2011  -12 hours
  Sun Mar 27 11:36:07 EEST 2011  -13 hours
  Sun Mar 27 10:36:07 EEST 2011  -14 hours
  Sun Mar 27 09:36:07 EEST 2011  -15 hours
  Sun Mar 27 08:36:07 EEST 2011  -16 hours
  Sun Mar 27 07:36:07 EEST 2011  -17 hours
  Sun Mar 27 06:36:07 EEST 2011  -18 hours
  Sun Mar 27 05:36:07 EEST 2011  -19 hours
  Sun Mar 27 04:36:07 EEST 2011  -20 hours  <-- just after change
  Sun Mar 27 02:36:07 EET 2011   -21 hours  <-- just before change
  Sun Mar 27 01:36:07 EET 2011   -22 hours
  Sun Mar 27 00:36:07 EET 2011   -23 hours
  Sat Mar 26 23:36:07 EET 2011   -24 hours

Observe that there is no 03:00:00-03:59:59 and March 27 is only 23
hours long that day.  It is shorter than 24 hours.  Using a 24 hour
calculation near midnight skips over that day completely.

With this table it should be obvious that date is behaving correctly
and the day that is shorter than 24 hours due to the conversion to DST
has caused -24 hours to skip completely over it.

Please see this FAQ entry for detailed explanation and hints on how to
avoid this problem.

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

Instead of doing calculations around DST I suggest using calculations
around noon.  I am not aware of any location that changes DST at noon
which makes it a much safer time to do date calculations.  The FAQ
entry provides examples.  Or if possible use UTC which also avoids the
problem by never switching to DST.

Bob

bug#8357: coreutils bug in date

[Heikki Orsila]

On Sun, Mar 27, 2011 at 06:04:37PM -0600, Bob Proulx wrote:
> Thank you for your bug report.  However I this is not a bug in date
> but a misunderstanding of how relative times and DST interact.
> ...
>  The string `tomorrow' is worth one day in the future (equivalent to
>   `day'), the string `yesterday' is worth one day in the past (equivalent
>   to `day ago').
> 
> So 'yesterday' or '24 hours ago' are equivalent.  These are exactly 24
> hours ago or 86400 seconds.  This is a critical point in your problem.

I see the problem, but IMO, the definition of yesterday should be changed
or there should be a new definition.

What about defining new units: 'calday', 'calyesterday', 'caltomorrow'? 
For example, $(date -d '1 calday ago' '+%F')? These would count actual 
calendar days rather than relative time (in units of 24 hours)?

Yes I know there is a work around in the doc you provided (thanks for that).

Heikki Orsila

bug#8357: coreutils bug in date

[Bob Proulx]

Heikki Orsila wrote:
> Bob Proulx wrote:
> > So 'yesterday' or '24 hours ago' are equivalent.  These are exactly 24
> > hours ago or 86400 seconds.  This is a critical point in your problem.
> 
> I see the problem, but IMO, the definition of yesterday should be changed
> or there should be a new definition.
> 
> What about defining new units: 'calday', 'calyesterday', 'caltomorrow'? 
> For example, $(date -d '1 calday ago' '+%F')? These would count actual 
> calendar days rather than relative time (in units of 24 hours)?

Something like that could be done.  I think there would be support for
that direction of development.

That is the problem when people put in features such as the relative
date calculations.  A simple but only partially implemented feature
sounds great but later causes an endless stream of problems.  They add
a partially nice feature but it isn't 100% perfect and then ten years
go by and people start to use it and then find the rough spots.  But
by then it is now a very long standing behavior and can't be changed.
Your suggestion to use different names avoids breaking the previous
behavior.  But still someone would need to actually do the work and
the code is not simple.  Working with human produced calender dates
has many traps and pitfalls.

Bob

bug#8357: coreutils bug in date

[Bob Proulx]

retitle 8357 Improve yesterday and tomorrow calculations for common cases
severity 8357 wishlist
thanks

Bob Proulx wrote:
> Heikki Orsila wrote:
> > Bob Proulx wrote:
> > > So 'yesterday' or '24 hours ago' are equivalent.  These are exactly 24
> > > hours ago or 86400 seconds.  This is a critical point in your problem.
> > 
> > I see the problem, but IMO, the definition of yesterday should be changed
> > or there should be a new definition.
> > 
> > What about defining new units: 'calday', 'calyesterday', 'caltomorrow'? 
> > For example, $(date -d '1 calday ago' '+%F')? These would count actual 
> > calendar days rather than relative time (in units of 24 hours)?
> 
> Something like that could be done.  I think there would be support for
> that direction of development.

There hasn't been any further discussion about the topic.  I don't
think this is going to be changed immediately.  It would need to be
discussed and an acceptable solution proposed and also someone would
need to actually do the work.  And so am reclassifying this ticket as
a wishlist to improve the date handling for the common cases of
yesterday and tomorrow just to document the issue.

Bob

Bug in 'date -d': timezone trouble

[PF]

Hi..

% date -d "07-09-10 10:45:43"
Mon Sep 10 10:45:43 PDT 2007

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

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

The date -d option is taking the time in the local time zone except when
you add time to it, when it reverts to GMT.  Explicitly mentioning the
timezone is a workaround.

Version of date (GNU coreutils): 5.97

Thanks!

-- 
PF <[EMAIL PROTECTED]>



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

bug#12650: Bug in date command

[Thiago Picharski]

Hello,

I'm trying run this command "date -d 12-10-21", but occur the follow
error, date: invalid date "12-10-21"
and finalize with error code 1.

Interestingly, when i run "date -d 12-10-20" or "date -d 12-10-22" this
work fine.

Thanks!

Thiago H. S. Picharski

bug#12650: Bug in date command

[Bob Proulx]

tags 12650 + moreinfo
thanks

Thiago Picharski wrote:
> I'm trying run this command "date -d 12-10-21", but occur the follow
> error, date: invalid date "12-10-21"
> and finalize with error code 1.

What timezone are you in?  Almost certainly that timezone experienced
a daylight savings time change and the time you are asking about does
not exist, is invalid.  "Spring forward and Fall back."  When DST
jumps forward then some times will not exist by act of law, not
technology.  Technology says use UTC but people like local time to
change from place to place.  :-)

Please read this reference and let us know if it covers your case or
not.

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

The basic problem is that when you specify 12-10-21 it means 
hours.  That is often when DST changes.  Better to specify noon
instead which is far from when DST changes.

  $ date -d "12-10-21 12:00"

Best would be to work in UTC to avoid DST issues entirely.

  $ date -u -d "12-10-21 12:00 UTC"

> Interestingly, when i run "date -d 12-10-20" or "date -d 12-10-22" this
> work fine.

Very likely those dates are valid.  Since you didn't say what timezone
you are working in I can't look to see what was happening there.

Bob

bug#15927: Bug in date command

[Claudio Pinto]

date --date=10/20/2013

result in

date: invalid date `10/20/2013'

version:

date (GNU coreutils) 8.13

bug#15927: Bug in date command

[Eric Blake]

tag 15927 needinfo
thanks

On 11/19/2013 05:23 AM, Claudio Pinto wrote:
> date --date=10/20/2013
> 
> result in
> 
> date: invalid date `10/20/2013'

We need more details, such as your current timezone.  I suspect that you
are running into a FAQ:

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

in that you are probably in a timezone where daylight savings changed
your time from midnight to 1am at the very start of that particular day,
and therefore where there is no effective midnight on that date.  But as
I don't know what timezone you are in, I haven't managed to reproduce it
locally (in my timezone, daylight savings changes occur at 2am rather
than midnight).

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



signature.asc
Description: OpenPGP digital signature

bug#15927: Bug in date command

[Bob Proulx]

tag 15927 + moreinfo
thanks

Claudio Pinto wrote:
> date --date=10/20/2013
> result in
> date: invalid date `10/20/2013'

In what timezone?

You didn't give your timezone therefore it is impossible to know for
sure but your problem statement matches one of the very common cases
where Daylight Saving Time changes and therefore creates an invalid
date in your timezone.

Since you don't specify a time the time of 00:00 implicit.  Better to
work with raw dates around 12:00 noon which avoids all known timezone
DST changes.  Using the raw 'date' output gives ambiguous timezones.
Better to use the standardized and unambiguous -R format.

  $ date -R --date=10/20/2013
  Sun, 20 Oct 2013 00:00:00 -0600

  $ date -R --date="10/20/2013 12:00"
  Sun, 20 Oct 2013 12:00:00 -0600

Even better is to always do date calculations in UTC to avoid any DST
problems entirely.

  $ date -u -R --date=10/20/2013
  Sun, 20 Oct 2013 00:00:00 +

Please see the FAQ for a detailed discussion of date and DST.

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

Bob

bug#15927: Bug in date command

[Bob Proulx]

tag 15927 - moreinfo + notabug
close 15927
thanks

Hello Claudio,

Please keep the bug log in the recipient list.  That way others in the
team on the mailing list can participate in the discussion.

Claudio Pinto wrote:
> Current default time zone: 'America/Sao_Paulo'
> Local time is now:  Ter Nov 19 17:10:40 BRST 2013.
> Universal Time is now:  Tue Nov 19 19:10:40 UTC 2013.
>
> Here in Brazil we have the time in an hour early.

Yes.  And that is the problem.  The time you have specified does not
exist.  That is what makes it an invalid time.

  $ zdump -v America/Sao_Paulo | grep Oct.*2013
  America/Sao_Paulo  Sun Oct 20 02:59:59 2013 UTC = Sat Oct 19 23:59:59 2013 
BRT isdst=0 gmtoff=-10800
  America/Sao_Paulo  Sun Oct 20 03:00:00 2013 UTC = Sun Oct 20 01:00:00 2013 
BRST isdst=1 gmtoff=-7200

In the America/Sao_Paulo timezone as shown above the seconds of the
clock tick to "Oct 19 23:59:59 2013 BRT" and the very next tick of the
clock is "Sun Oct 20 01:00:00 2013 BRST".  But you are asking for
"Sun Oct 20 00:00:00" which does not exist in either BRT or BRST.

Note that this is not a technology issue.  This is an issue of
changing the clock for Daylight Saving Time.  Most countries do this
by an act of government.

> Removing a difference an hour, with the command below, the error does not
> happen ...
> date --date="10/20/2013 01:00"
> with the command below error appears:
> date --date="10/20/2013 00:59"

Correct.  Because those are invalid according to your
America/Sao_Paulo timezone.  To avoid those errors either use UTC
which does not change for Daylight Saving Time or use 12:00 noon to
avoid being near the time that it changes.

Since this is a bug in usage and not a bug in the date calculations I
am going to close the bug report.  However if things are still not
clear please feel free to follow up with any responses or comments and
we can keep discussing it.

Please keep the bug log address in the recipient list.

Bob

bug#23270: Bug in 'date' command

[Maarten]

Hello,
 

I recently discovered a bug, or at least unexpected behavior, about the ‘date’ 
command which I want to report.  The bug is related to the moment of ‘daylight 
saving time’ (summertime / wintertime)

 

On Monday the 28st of march at 0.15 I run an automated script with the command:

# date -d yesterday +%d-%m-%Y

 

The return of that command was 26-03-2016 where I expected 27-03-2016. (2 days 
before, where I expected only 1 day before)

 

My only explanation is that the command is run the day after 27-3-2016, the day 
that the our region switched from summertime to wintertime.  At 2.00 the clock 
is forwarded to 3.00 so the day is only 23 hours long. When I request a 
‘yesterday at 28-03-20160.15 the request is about 24 hours before.  The answer 
is 26-03-2016 at 23.15.

 

Anyway, a ‘date -d yesterday’ should return 1 day before, not 2 days before.  
In my case, as a result of it, an automated shell script went wrong.

 

Please, can you fix this ‘daylight saving time’ related bug?

 

More info:

 

Timezone: Amsterdam, europe

 

# cat /etc/redhat-release

Red Hat Enterprise Linux Server release 6.7 (Santiago)

 

# date --version

date (GNU coreutils) 8.4

Copyright (C) 2010 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.

 

Many thanks!  If you need further information, please let me know.

 

Best regards,

 

Maarten Mastbroek

 

bug#23270: Bug in 'date' command

[Assaf Gordon]

tag 23270 notabug
close 23270
thanks

Hello Maarten Mastbroek,

On 04/11/2016 12:36 PM, Maarten wrote:

I recently discovered a bug, or at least unexpected behavior, about
the ‘date’ command which I want to report.  The bug is related to the
moment of ‘daylight saving time’ (summertime / wintertime)


This is not a bug (perhaps indeed unexpected behavior).

It is explained in the Coreutils FAQ:
 
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

Your diagnosis is correct:


[...] When I request a ‘yesterday' request is about 24 hours before.


In GNU 'date', the relative period of 'yesterday' is defined exactly as 24 
hours,
regardless of daylight saving time.

The recommended way to perform all relative day calculations is to specify 
12:00pm,
so that adding/subtracting 24-hours avoids DST issues.

Example:
   date -d "12:00 yesterday"  +%d-%m-%Y

(similarly, when calculating relatives months, it is recommended to specify the 
15th of the month, to avoid leap-years issues.)


As such I'm closing this bug, but discussion can continue by replying to this 
thread.

regards,
 - assaf

bug#12650: Bug in date command

[Assaf Gordon]

close 12650
stop

(triaging old bugs)

On 14/10/12 05:28 PM, Bob Proulx wrote:


Thiago Picharski wrote:

I'm trying run this command "date -d 12-10-21", but occur the follow
error, date: invalid date "12-10-21"
and finalize with error code 1.


[...]
The basic problem is that when you specify 12-10-21 it means 
hours.  That is often when DST changes.  Better to specify noon
instead which is far from when DST changes.


[...]

Very likely those dates are valid.  Since you didn't say what timezone
you are working in I can't look to see what was happening there.



With no further comments to Bob's explanation in 6 years,
I'm closing this bug.

-assaf

bug#37060: bug in date / coreutils

[jensbaltrusch]

Hi,

I believe there is a bug in the date utility.

My system is set to Berlin time, now daylight saving time.

When I put in

  date --date='TZ="Europe/Berlin" now'

I get correctly

  Sat 17 Aug 05:11:18 CEST 2019

However, putting in

  date --date='TZ="America/Los_Angeles" now'

yields

  Sat 17 Aug 14:12:03 CEST 2019

which is nonsense. Also, putting in

  date --date='TZ="Asia/Shanghai" now'

giving

  Fri 16 Aug 23:13:36 CEST 2019

which is definitely wrong, as I am currently in China where the sun is  
up and shining.




I get from date --version the following:


date (GNU coreutils) 8.23
Copyright (C) 2014 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.


My system is

Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u1 (2017-02-22)  
x86_64 GNU/Linux



I get the same kind of error using 'today' instead of 'now', or  
'tomorrow', '1 hour ago', etc.


In case you need further information, please do not hesitate to contact me.

Best,
Jens Baltrusch

bug#37060: bug in date / coreutils

[Paul Eggert]

I think that bug was fixed in 2017, and your coreutils version 8.23 predates the 
fix. I suggest upgrading to the current version (8.31) of coreutils, as 8.23 is 
pretty old anyway.

bug#10182: Century bug in date utility?

[Bob Proulx]

Krzysztof Kowalski wrote:
> For a test I changed system time to 1997 and date utility returned 20
> century as well :)

Of course you know you don't need to change the system time to test
this.  You can do it easily with date.

  $ date -d '1997-01-01 12:00 UTC' +%C
  19

Bob

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

Bug(?) in date concerning 'tomorrow' and 'day'

[Jonas Mixter]

Hi!
I've found that date handles the relative items "tomorrow" and "day"
differently. According to the info-page these should be equivalent. (I've
read this in: (coreutils.info)Relative items in date strings)

The oddity that I've found is that tomorrow doesn't add a full day when
daylight saving time starts or ends.

In Sweden daylight savings is ending at October 26 this year.
If one run `date --date="2003-10-26 tomorrow"` to convert an iso-8601 date
into local time (and add a day at the same time), one doesn't get the date
and time of the 27 October but instead the time 23:00 at the 26'th of
October.
If one instead run `date --date="2003-10-26 day"` one get the time and date
of midnight, October 27.

This also seems to apply to the relatives yesterday/day ago. It both applies
to the start and end of daylight savings.
If this is a desired behavior of the relative tomorrow, the difference
between tommorow and day should perhaps be pointed out in the info-page.

I'm not on the bug-tracking mailinglist, so any replies (wich are warmly
welcome) must also be done to my e-mailadress.
I would also like to thank for all the great software that FSF and the GNU
project has given the world!

Best regards, Jonas Mixter



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

coreutils: bug in date --iso-8601={seconds,ns}?

[Johannes Truschnigg]

Dear GNU maintainer/team/email-dude,

in thre process of writing an Atom-feed-generator in bash, I discovered what 
MIGHT be a bug/documentation misinterpretation in GNU date's --iso-8601 
switch when invoked with "ns" or "seconds" as a parameter.

RFC3339 and some documents regarding ISO 8601 I could find on the web quickly 
seem to suggest that the time-offset component of the output should match the 
regex /\d\d:\d\d/; date, however, matches /\d\d\d\d/.

As said, I don't know if the actual ISO 8601 standard specifies that as fair 
game, as I don't know where I could take a look at it - but it might not harm 
investigating if you aren't completely sure about the correct behaviour 
either...

Anyway, thanks for taking the time and making coreutils available to us mere 
mortals in the first place - happy hacking! :-)

-- 
with best regards:
- Johannes Truschnigg ( [EMAIL PROTECTED] )

www: http://johannes.truschnigg.info/
phone: +43 650 2 17
jabber: [EMAIL PROTECTED]

Please do not bother me with HTML-eMail or attachments. Thank you.


signature.asc
Description: This is a digitally signed message part.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

a bug in date concerning daylight saving time

[Lao DanTong]

Dear maintainers of coreutils,

I found what is likely to be a bug in date. It does not recognise as valid 
the date when clock jumps one hour due to DST. here in Brazil we use this 
rule:


RuleBrazil  2007max -   Oct Sun>=8   0:00   1:00S
RuleBrazil  2008max -   Feb Sun>=15  0:00   0   -

so DST will start next October, 14. date says that --date=2007-10-14 is 
not a valid date:


$ ./date --version
date (GNU coreutils) 6.9
...
$ ./date --date=2007-10-14
./date: invalid date `2007-10-14'

but no problem if time is in UTC:

$ ./date --date=2007-10-14 -u
Sun Oct 14 00:00:00 UTC 2007

taking an older version of date (the one on board slackware 10):

$ date --date=2007-10-14
Sun Oct 14 01:00:00 BRST 2007

it works as expected.

It looks like that some code introduced in date to prevent it from 
accepting wrong dates like 2007-02-31, broke it in the transition to DST.


date from coreutils 6.9:

$ ./date --date=2007-02-31
./date: invalid date `2007-02-31'

date from slackware-10:

$ date --date=2007-02-31
Sat Mar  3 00:00:00 BRT 2007

which is, by the way, a very consistent result!

May I suggest you to rollback to the way dates were treated as in the 
slackware-10 version, coreutils 5.2. I'll try to patch lib/getdate.c but 
I'm afraid I have neither time nor skills enough for the task.


thanks,
--
Danton Nunes  |Informática, Consultoria e Serviços de Acesso à Internet
InterNexo Ltda.   |http://www.inexo.com.br/ e-mail:[EMAIL PROTECTED]
S.J.Campos,BRASIL |  PGP: 02 D1 E2 DF 21 EC 48 69 3F D5 4D 1B 5D 73 F4 B5


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

bug#16386: maybe a small Bug in date?

[thomas.dohl]

Hello,

could this be a bug in date?
date --version
date (GNU coreutils) 8.4
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.

bug report:
--
OK: date-> Tue Jan
7 16:27:06 CET 2014

OK: date +%V_%Y -d "last wednesday" -> 01_2014
OK: date +%V_%Y -d "last wednesday +1 week" -> 02_2014
...
OK: date +%V_%Y -d "last wednesday +51 week"-> 52_2014
WRONG:  date +%V_%Y -d "last wednesday +52 week"-> 01_2014
This should be 01_2015: 
OK: date +%V_%Y -d "last wednesday +53 week"-> 02_2015
OK: date +%V_%Y -d "last wednesday +54 week"-> 03_2015
...



My system:
uname -a
Linux ... 2.6.32-431.1.2.0.1.el6.x86_64 #1 SMP Fri Dec 13 13:06:13
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
less /etc/redhat-release
CentOS release 6.5 (Final)


Thanks and best regards.
Thomas Dohl


Mit freundlichen Grüßen,
Soluvia IT-Services GmbH
Netz & Security / Rechenzentrum & Infrastruktur
Thomas Dohl

Telefon: +49 (0)621-290-3839
Fax:  +49 (0)621-290-2677
E-Mail:  thomas.d...@soluvia.de
Internet: www.soluvia-it-services.de

Soluvia IT-Services GmbH . Uhlenkrog 32 . 24113 Kiel
Büro Mannheim: Luisenring 49, 68159 Mannheim
Handelsregister-Nr. HRB 7458Ki, Sitz und Amtsgericht: Kiel
Geschäftsführer: Dr. Dirk Bevers, Dr. Simon Kalvoda

Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser E-Mail ist nicht gestattet.





smime.p7s
Description: S/MIME cryptographic signature

bug#16386: maybe a small Bug in date?

[Eric Blake]

tag 16386 notabug
thanks

On 01/07/2014 08:37 AM, thomas.d...@soluvia.de wrote:
> Hello,
> 
> could this be a bug in date?

Thanks for the report.  However, this is not a bug in date, but a
misunderstanding on your part, covered in our FAQ.

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

> 
> OK:   date +%V_%Y -d "last wednesday" -> 01_2014

Do not mix %V and %Y.  %V goes with %G, %Y goes with %U or %W.

> OK:   date +%V_%Y -d "last wednesday +1 week" -> 02_2014
> ...
> OK:   date +%V_%Y -d "last wednesday +51 week"-> 52_2014
> WRONG:date +%V_%Y -d "last wednesday +52 week"-> 01_2014
> This should be 01_2015:   

No, you are using the wrong format string.  When you mix two different
formats that use different notions of when a year rolls over, you are
bound to get confusing results.  But those results are correct, once you
re-read the documentation of what those format strings represent.

> Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen

This disclaimer is unenforceable on a publicly-archived mailing list.
It is considered poor email etiquette to open source lists to use your
employer's email if they are going to tack on garbage.

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



signature.asc
Description: OpenPGP digital signature

bug#17161: Bug in date arithmetic of date

[Marc R.J. Brevoort]

Hi,

There seems to be some weirdness in date arithmetic when dates
include a time stamp (and all provided in ISO formatting):

Correct:

mrjb@THE-D-MRJB:~$ date -d "2014-03-11" +"%Y-%m-%d %H:%M:%S"
2014-03-11 00:00:00

mrjb@THE-D-MRJB:~$ date -d "2014-03-11 -1 day" +"%Y-%m-%d %H:%M:%S"
2014-03-10 00:00:00

Incorrect:

mrjb@THE-D-MRJB:~$ date -d "2014-03-11 12:34 -2 hours" +"%Y-%m-%d 
%H:%M:%S"

2014-03-11 15:34:00
mrjb@THE-D-MRJB:~$ date -d "2014-03-11 12:34 +2 hours" +"%Y-%m-%d 
%H:%M:%S"

2014-03-11 11:34:00
mrjb@THE-D-MRJB:~$ date -d "2014-03-11 12:34 -1 day" +"%Y-%m-%d %H:%M:%S"
2014-03-12 13:34:00
mrjb@THE-D-MRJB:~$ date -d "2014-03-11 12:34 +1 day" +"%Y-%m-%d %H:%M:%S"
2014-03-12 11:34:00

bug#17161: Bug in date arithmetic of date

[Eric Blake]

tag 17161 notabug
thanks

On 04/01/2014 05:30 AM, Marc R.J. Brevoort wrote:
> Hi,
> 
> There seems to be some weirdness in date arithmetic when dates
> include a time stamp (and all provided in ISO formatting):

The weirdness is caused by your choice of locale, coupled with your
government's use of daylight savings, and not a bug in 'date'.

See also the FAQ:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

> mrjb@THE-D-MRJB:~$ date -d "2014-03-11 12:34 -2 hours" +"%Y-%m-%d %H:%M:%S"
> 2014-03-11 15:34:00
> mrjb@THE-D-MRJB:~$ date -d "2014-03-11 12:34 +2 hours" +"%Y-%m-%d %H:%M:%S"
> 2014-03-11 11:34:00
> mrjb@THE-D-MRJB:~$ date -d "2014-03-11 12:34 -1 day" +"%Y-%m-%d %H:%M:%S"
> 2014-03-12 13:34:00
> mrjb@THE-D-MRJB:~$ date -d "2014-03-11 12:34 +1 day" +"%Y-%m-%d %H:%M:%S"
> 2014-03-12 11:34:00

These examples happen to cross a daylight savings boundary in your
current locale.  If you would amend your example to include time zone
names, you would see the name change, as evidence that the dates listed
are really 2 (or 24) hours apart, even though the wall clock time
appears to be 1 hour off.

You can also force date to operate on --utc, which does not observe
daylight savings, and therefore is immune to these oddities.

As such, I'm closing this as not a bug.

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



signature.asc
Description: OpenPGP digital signature

bug#23008: Daylight Savings Time Bug in Date

[Sarah Corriher]

We detected a bug in the date program, which correlates to the daylight 
savings time change. A day disappeared from the date program between 
12:00 AM and 1:00 AM on 3/14/16. The date program began working as 
expected immediately after 1:00 AM. Here is the bizarre output that I 
got for basic commands on 3/14/16:


   $ date -d -0days +%Y-%m-%d
   2016-03-14

   $ date -d -1days +%Y-%m-%d
   2016-03-12

Notice that I was unable to obtain the expected output of 2016-03-13 for 
the day prior. I was able to reproduce this using version 8.13 on 
Debian, and 8.21 on Mint.


--
Sarah C. Corriher
Co-author of "Defy Your Doctor and Be Healed"
336-528-4120
http://HealthWyze.org

We're Health Wyze. Have you told your friends about us?

bug#23008: Daylight Savings Time Bug in Date

[Eric Blake]

tag 23008 notabug
thanks

On 03/13/2016 11:24 PM, Sarah Corriher wrote:
> We detected a bug in the date program, which correlates to the daylight
> savings time change.

Thanks for the report.  However, this is not a bug, but a FAQ that gets
asked twice a year.  See:

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

> 
>$ date -d -0days +%Y-%m-%d
>2016-03-14
> 
>$ date -d -1days +%Y-%m-%d
>2016-03-12

When trying to add units of 24 hours (the -1days), only to then display
just a day and not an hour, it's best to start from noon rather than
from a time that might be impacted by daylight savings:

# date -d '12:00pm 2014-03-14 -1day' +%Y-%m-%d
2016-03-13

Otherwise, as you discovered, starting at midnight and going 24 hours
across a day with only 23 hours is likely to skip that day.

I'm closing this as not a bug, but feel free to reply with further
questions or comments.

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



signature.asc
Description: OpenPGP digital signature

Re: Bug(?) in date concerning 'tomorrow' and 'day'

[Paul Eggert]

"Jonas Mixter" <[EMAIL PROTECTED]> writes:

> In Sweden daylight savings is ending at October 26 this year.
> If one run `date --date="2003-10-26 tomorrow"` to convert an iso-8601 date
> into local time (and add a day at the same time), one doesn't get the date
> and time of the 27 October but instead the time 23:00 at the 26'th of
> October.
> If one instead run `date --date="2003-10-26 day"` one get the time and date
> of midnight, October 27.

Thanks for the bug report.  I think this bug was fixed in 1999 but the
fix got lost somehow.  I installed the following patch into gnulib.

2003-09-03  Paul Eggert  <[EMAIL PROTECTED]>

* getdate.y (relative_time_table): Use tDAY_UNIT for "tomorrow",
"yesterday", "today", and "now" rather than tMINUTE_UNIT.  Of
course with correspondingly smaller numbers for tomorrow and
yesterday.  From Tadayoshi Funaba.  Originally installed into
sh-utils on 1999-08-07, but the patch got lost (I guess during the
coreutils merge?).

Index: getdate.y
===
RCS file: /cvsroot/gnulib/gnulib/lib/getdate.y,v
retrieving revision 1.78
retrieving revision 1.79
diff -p -u -r1.78 -r1.79
--- getdate.y   5 Aug 2003 05:14:20 -   1.78
+++ getdate.y   3 Sep 2003 07:11:45 -   1.79
@@ -527,10 +527,10 @@ static table const time_units_table[] =
 /* Assorted relative-time words. */
 static table const relative_time_table[] =
 {
-  { "TOMORROW",tMINUTE_UNIT,   24 * 60 },
-  { "YESTERDAY",tMINUTE_UNIT,  - (24 * 60) },
-  { "TODAY",   tMINUTE_UNIT,0 },
-  { "NOW", tMINUTE_UNIT,0 },
+  { "TOMORROW",tDAY_UNIT,   1 },
+  { "YESTERDAY",tDAY_UNIT, -1 },
+  { "TODAY",   tDAY_UNIT,   0 },
+  { "NOW", tDAY_UNIT,   0 },
   { "LAST",tUNUMBER,   -1 },
   { "THIS",tUNUMBER,0 },
   { "NEXT",tUNUMBER,1 },


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

Re: coreutils: bug in date --iso-8601={seconds,ns}?

[Philip Rowlands]

On Fri, 22 Aug 2008, Johannes Truschnigg wrote:

in thre process of writing an Atom-feed-generator in bash, I discovered 
what MIGHT be a bug/documentation misinterpretation in GNU date's 
--iso-8601 switch when invoked with "ns" or "seconds" as a parameter.


--iso-8601 is deprecated since coreutils 5.90.


RFC3339 and some documents regarding ISO 8601 I could find on the web quickly
seem to suggest that the time-offset component of the output should match the
regex /\d\d:\d\d/; date, however, matches /\d\d\d\d/.


I think --rfc-3339=seconds will do what you want.


Cheers,
Phil


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

Re: a bug in date concerning daylight saving time

[Bob Proulx]

Lao DanTong wrote:
> I found what is likely to be a bug in date. It does not recognise as valid 
> the date when clock jumps one hour due to DST. here in Brazil we use this 
> rule:
> 
> RuleBrazil  2007max -   Oct Sun>=8   0:00   1:00S
> RuleBrazil  2008max -   Feb Sun>=15  0:00   0   -

Would you do me a favor and show the output of zdump for this year for
your timezone?  Here is an example for my timezone of US/Mountain.

  $ zdump -v US/Mountain | grep 2007
  US/Mountain  Sun Mar 11 08:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 MST 
isdst=0 gmtoff=-25200
  US/Mountain  Sun Mar 11 09:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 MDT 
isdst=1 gmtoff=-21600
  US/Mountain  Sun Nov  4 07:59:59 2007 UTC = Sun Nov  4 01:59:59 2007 MDT 
isdst=1 gmtoff=-21600
  US/Mountain  Sun Nov  4 08:00:00 2007 UTC = Sun Nov  4 01:00:00 2007 MST 
isdst=0 gmtoff=-25200

What is the output for your timezone?  I believe this will be useful
information in understanding what is happening.

Please remember to keep the bug-coreutils mailing list in the To: or
Cc: list so that all may participate in the discussion.

Thanks
Bob


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

Re: a bug in date concerning daylight saving time

[John Cowan]

Lao DanTong scripsit:

> I found what is likely to be a bug in date. It does not recognise as valid 
> the date when clock jumps one hour due to DST. here in Brazil we use this 
> rule:
> 
> RuleBrazil  2007max -   Oct Sun>=8   0:00   1:00S
> RuleBrazil  2008max -   Feb Sun>=15  0:00   0   -
> 
> so DST will start next October, 14. date says that --date=2007-10-14 is 
> not a valid date:
> 
> $ ./date --version
> date (GNU coreutils) 6.9
> ...
> $ ./date --date=2007-10-14
> ./date: invalid date `2007-10-14'

That looks exactly right to me.  2007-10-14 means 2007-10-14T00:00:00, but
that second does not exist in any timezone observing the "Brazil" rules:
time jumps directly from 2007-10-13T23:59:59 to 2007-10-14T01:00:00.
Internal evidence shows that the timezone in your examples is
America/Sao_Paulo, but this rule set also applies to America/Campo_Grande
and America/Cuiaba, the only other two Brazilian time zones currently
observing DST.

Maybe you want to argue that dates without times should mean the first
second of the day rather than 00:00:00.

> but no problem if time is in UTC:
> 
> $ ./date --date=2007-10-14 -u
> Sun Oct 14 00:00:00 UTC 2007

Naturally, since 2007-10-14T00:00:00 of course exists in UTC.

-- 
On the Semantic Web, it's too hard to prove John Cowan[EMAIL PROTECTED]
you're not a dog.  --Bill de hOra   http://www.ccil.org/~cowan


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

Re: a bug in date concerning daylight saving time

[Lao DanTong]

On Fri, 28 Sep 2007, Bob Proulx wrote:


Lao DanTong wrote:

I found what is likely to be a bug in date. It does not recognise as valid
the date when clock jumps one hour due to DST. here in Brazil we use this
rule:

RuleBrazil  2007max -   Oct Sun>=8   0:00   1:00S
RuleBrazil  2008max -   Feb Sun>=15  0:00   0   -


Would you do me a favor and show the output of zdump for this year for
your timezone?  Here is an example for my timezone of US/Mountain.


voila:

# zdump -v America/Sao_Paulo | fgrep 2007
America/Sao_Paulo  Sun Feb 25 01:59:59 2007 UTC = Sat Feb 24 23:59:59 2007 BRST 
isdst=1 gmtoff=-7200
America/Sao_Paulo  Sun Feb 25 02:00:00 2007 UTC = Sat Feb 24 23:00:00 2007 BRT 
isdst=0 gmtoff=-10800
America/Sao_Paulo  Sun Oct 14 02:59:59 2007 UTC = Sat Oct 13 23:59:59 2007 BRT 
isdst=0 gmtoff=-10800
America/Sao_Paulo  Sun Oct 14 03:00:00 2007 UTC = Sun Oct 14 01:00:00 2007 BRST 
isdst=1 gmtoff=-7200



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

Re: a bug in date concerning daylight saving time

[Lao DanTong]

On Fri, 28 Sep 2007, John Cowan wrote:


That looks exactly right to me.  2007-10-14 means 2007-10-14T00:00:00, but
that second does not exist in any timezone observing the "Brazil" rules:
time jumps directly from 2007-10-13T23:59:59 to 2007-10-14T01:00:00.
Internal evidence shows that the timezone in your examples is
America/Sao_Paulo, but this rule set also applies to America/Campo_Grande
and America/Cuiaba, the only other two Brazilian time zones currently
observing DST.


Yes, it's America/Sao_Paulo.

This semantics makes sense, however I think the 'old' behaviour of date is 
much more practical:


$ date --date=2007-10-14
Sun Oct 14 01:00:00 BRST 2007

that is to interpret 2007-10-14 as 2007-10-14T01:00:00, i.e., the very 
first second of that day.



Maybe you want to argue that dates without times should mean the first
second of the day rather than 00:00:00.


Yes. this makes a lot of sense, don't you think? Notice that date reports 
illegal date for a date specification like --date=2007-10-14+2hours, which 
should be legal and render as 2007-10-14T03:00:00




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

Re: a bug in date concerning daylight saving time

[Bob Proulx]

Lao DanTong wrote:
> $ ./date --date=2007-10-14
> ./date: invalid date `2007-10-14'

> America/Sao_Paulo  Sun Oct 14 02:59:59 2007 UTC = Sat Oct 13 23:59:59 2007 
> BRT isdst=0 gmtoff=-10800
> America/Sao_Paulo  Sun Oct 14 03:00:00 2007 UTC = Sun Oct 14 01:00:00 2007 
> BRST isdst=1 gmtoff=-7200

This confirms the analysis given by John when he said:

John Cowan wrote:
> 2007-10-14 means 2007-10-14T00:00:00, but that second does not exist
> in any timezone observing the "Brazil" rules: time jumps directly from
> 2007-10-13T23:59:59 to 2007-10-14T01:00:00.

The timezone defines that the second before in the old timezone is Sat
Oct 13 23:59:59 2007 BRT and the second after in the new timezone is
Sun Oct 14 01:00:00 2007 BRST.  There are no seconds between.

The date program uses 2007-10-14 to mean 2007-10-14 00:00:00 and as
defined by the zoneinfo data that time does not exist.  The date
truly is an invalid date.

Bob



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

Re: a bug in date concerning daylight saving time

[Bob Proulx]

Lao DanTong wrote:
> John Cowan wrote:
> >Maybe you want to argue that dates without times should mean the first
> >second of the day rather than 00:00:00.
> 
> Yes. this makes a lot of sense, don't you think? Notice that date reports 
> illegal date for a date specification like --date=2007-10-14+2hours, which 
> should be legal and render as 2007-10-14T03:00:00

What should be done for other invalid dates such as Feb 30th?

Bob

BTW... Here is the NEWS item for this change:

* Major changes in release 5.3.0 (2005-01-08) [unstable]

  Date syntax as used by date -d, date -f, and touch -d has been
  changed as follows:

Dates like `January 32' with out-of-range components are now rejected.

Dates can have fractional time stamps like 2004-02-27 14:19:13.489392193.

Dates can be entered via integer counts of seconds since 1970 when
prefixed by `@'.  For example, [EMAIL PROTECTED]' represents 1970-01-01 
00:05:21 UTC.

Time zone corrections can now separate hours and minutes with a colon,
and can follow standard abbreviations like "UTC".  For example,
"UTC +0530" and "+05:30" are supported, and are both equivalent to "+0530".

Date values can now have leading TZ="..." assignments that override
the environment only while that date is being processed.  For example,
the following shell command converts from Paris to New York time:

  TZ="America/New_York" date --date='TZ="Europe/Paris" 2004-10-31 06:30'

  `date' has a new option --iso-8601=ns that outputs
  nanosecond-resolution time stamps.


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

Re: a bug in date concerning daylight saving time

[Lao DanTong]

On Fri, 28 Sep 2007, Bob Proulx wrote:


Lao DanTong wrote:

John Cowan wrote:

Maybe you want to argue that dates without times should mean the first
second of the day rather than 00:00:00.


Yes. this makes a lot of sense, don't you think? Notice that date reports
illegal date for a date specification like --date=2007-10-14+2hours, which
should be legal and render as 2007-10-14T03:00:00


What should be done for other invalid dates such as Feb 30th?


good point. I think Feb 30th could produce:

$ date --date 2007-02-30
Fri Mar  2 00:00:00 BRT 2007

as the date used to do in old times. I don't think this could be harmful 
in any way, and the result IS meaningful.




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

Re: a bug in date concerning daylight saving time

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Lao DanTong on 9/28/2007 5:43 PM:
> $ date --date 2007-02-30
> Fri Mar  2 00:00:00 BRT 2007
> 
> as the date used to do in old times. I don't think this could be harmful
> in any way, and the result IS meaningful.

But what if I wanted it to print this instead?
Wed Feb 28 00:00:00 BRT 2007

The point of making it an error was because no matter how you resolve an
ambiguity, someone else wants it resolved in the opposite direction.  The
easiest way to treat both demands equally is to complain loudly that it is
ambiguous, rather than trying one of the options and guessing wrong.

- --
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

iD8DBQFG/ZuI84KuGfSFAYARApaSAJ9tyEb1qhI49hBT+Ca2+8l0SSdxywCfWO8X
vR2Wey1ZFeW+4pa/JV2ahcE=
=bNpo
-END PGP SIGNATURE-


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

Re: a bug in date concerning daylight saving time

[Lao DanTong]

On Fri, 28 Sep 2007, Eric Blake wrote:


as the date used to do in old times. I don't think this could be harmful
in any way, and the result IS meaningful.


But what if I wanted it to print this instead?
Wed Feb 28 00:00:00 BRT 2007

The point of making it an error was because no matter how you resolve an
ambiguity, someone else wants it resolved in the opposite direction.  The
easiest way to treat both demands equally is to complain loudly that it is
ambiguous, rather than trying one of the options and guessing wrong.


King Salomon's way. All right, I'll no longer argue on this matter. Thanks 
for your answers and keep on doing such a good job that is to maintain 
good quality free software.


merry 2007-01-359!


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

bug#13372: bug in date with last week calculation

[Tomas Dabašinskas]

Hi, 

I'm getting week number 53 when trying to get last week on Mon Jan  7 09:46:19 
EST 2013:

$ date
Mon Jan  7 09:46:19 EST 2013
$ date -d'last week' +%W
53

Expecting to get week 1

Many thanks!
-- 
Tomas Dabašinskas | Engineering Content Services | Red Hat Asia Pacific

bug#13372: bug in date with last week calculation

[Paul Eggert]

On 01/06/2013 03:48 PM, Tomas Dabašinskas wrote:
> $ date
> Mon Jan  7 09:46:19 EST 2013

Something odd with your time zone setting?
As I write this, the current time is
Sun Jan  6 20:59:42 EST 2013.

bug#13372: bug in date with last week calculation

[Tomas Dabašinskas]

- Original Message -
> Something odd with your time zone setting?
> As I write this, the current time is
> Sun Jan  6 20:59:42 EST 2013.
> 

Paul, 
Many thanks for getting back.
The time zone I'm using is GMT+10 (Australian East Std time).
I'm sorry, I should have clarified this in my bug report, I don't think it's 
timezone related tough...

Regards,
-- 
Tomas Dabašinskas | Engineering Content Services | Red Hat Asia Pacific

bug#13372: bug in date with last week calculation

[Paul Eggert]

On 01/06/2013 06:18 PM, Tomas Dabašinskas wrote:
> The time zone I'm using is GMT+10 (Australian East Std time).

Ah, in that case week 53 is correct, no?

$ export TZ=Australia/Sydney; date; date -d'last week'; date -d'last week' +%W
Mon Jan  7 13:41:02 EST 2013
Mon Dec 31 13:41:02 EST 2012
53

bug#13372: bug in date with last week calculation

[Tomas Dabašinskas]

- Original Message -
> Ah, in that case week 53 is correct, no?
> 
> $ export TZ=Australia/Sydney; date; date -d'last week'; date -d'last
> week' +%W
> Mon Jan  7 13:41:02 EST 2013
> Mon Dec 31 13:41:02 EST 2012
> 53
> 
> 

Paul, I'm using coreutils v8.4 so I think that could be my problem...

-- 
Tomas Dabašinskas | Engineering Content Services | Red Hat Asia Pacific

bug#13372: bug in date with last week calculation

[Bob Proulx]

Tomas Dabašinskas wrote:
> I'm getting week number 53 when trying to get last week on
> Mon Jan  7 09:46:19 EST 2013:
>
> $ date
> Mon Jan  7 09:46:19 EST 2013
> $ date -d'last week' +%W
> 53
>
> Expecting to get week 1

You are using %W which is described as:

  `%W'
 week number of year, with Monday as first day of week
 (`00'...`53').  Days in a new year preceding the first Monday are
 in week zero.

And so:

 December 2012  
  Mo Tu We Th Fr Sa Su
  24 25 26 27 28 29 30  <-- week 52
  31<-- week 53
  January 2013
  Mo Tu We Th Fr Sa Su
  1  2  3  4  5  6  <-- week 0
   7  8  9 10 11 12 13  <-- week 1
  14 15 16 17 18 19 20  <-- week 2
  21 22 23 24 25 26 27
  28 29 30 31

Since you are reporting your current time as Jan 7 then Dec 31 would
be last week.  Dec 31 would be week 53.

  $ env TZ=Australia/Sydney date -d 'last week' -R
  Mon, 31 Dec 2012 16:59:04 +1100

And so:

  $ env TZ=Australia/Sydney date -d 'last week' +%W
  53

  $ env TZ=Australia/Sydney date -d 'Dec 31 2012 12:00 +' +%W
  53

There are multiple different definitions for week numbers depending
upon weeks starting on Sunday, starting on Monday, and so forth.

Also related are:

  `%U'
 week number of year, with Sunday as the first day of the week
 (`00'...`53').  Days in a new year preceding the first Sunday are
 in week zero.

  `%V'
 ISO week number, that is, the week number of year, with Monday as
 the first day of the week (`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.)

You might want to look at the strftime man page for an alternate
description:

  man 3 strftime

   %U The  week  number of the current year as a decimal number, range
  00 to 53, starting with the first Sunday as  the  first  day  of
  week 01.  See also %V and %W.

   %V The  ISO 8601  week  number (see NOTES) of the current year as a
  decimal number, range 01 to 53, where week 1 is the  first  week
  that  has  at least 4 days in the new year.  See also %U and %W.
  (SU)

   %W The  week  number of the current year as a decimal number, range
  00 to 53, starting with the first Monday as  the  first  day  of
  week 01.

   ISO 8601 Week Dates
   %G, %g, and %V yield values calculated from the week-based year defined
   by the ISO 8601 standard.  In this system, weeks start on a Monday, and
   are numbered from 01, for the first week, up to 52 or 53, for the  last
   week.  Week 1 is the first week where four or more days fall within the
   new year (or, synonymously, week 01 is: the first week of the year that
   contains  a  Thursday;  or,  the  week that has 4 January in it).  When
   three of fewer days of the first calendar week of  the  new  year  fall
   within that year, then the ISO 8601 week-based system counts those days
   as part of week 53 of the preceding year.  For example, 1 January  2010
   is a Friday, meaning that just three days of that calendar week fall in
   2010.  Thus, the ISO 8601 week-based system considers these days to  be
   part  of  week 53 (%V) of the year 2009 (%G) ; week 01 of ISO 8601 year
   2010 starts on Monday, 4 January 2010.

Perhaps you are looking for the ISO week date %V?  And if just doing
calculations I suggest using UTC.

  $ date -u -d 'Dec 31 2012 12:00 +' +%V
  01

The 'ncal' program provides a useful but unusual way to display the
ISO week numbers:

  $ ncal -A 1 -w 12 2012
  December 2012 January 2013
  Su 2  9 16 23 30 6 13 20 27
  Mo 3 10 17 24 31 7 14 21 28
  Tu 4 11 18 25 1  8 15 22 29
  We 5 12 19 26 2  9 16 23 30
  Th 6 13 20 27 3 10 17 24 31
  Fr 7 14 21 28 4 11 18 25
  Sa  1  8 15 22 29 5 12 19 26
 48 49 50 51 52  1  1  2  3  4  5

You should also read the FAQ:

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

No one is ever happy with week numbers.

Bob

bug#13372: bug in date with last week calculation

[Tomas Dabašinskas]

- Original Message -
> You are using %W which is described as:
> 
>   `%W'
>  week number of year, with Monday as first day of week
>  (`00'...`53').  Days in a new year preceding the first Monday
>  are
>  in week zero.
> 
> And so:
> 
>  December 2012
>   Mo Tu We Th Fr Sa Su
>   24 25 26 27 28 29 30  <-- week 52
>   31<-- week 53
>   January 2013
>   Mo Tu We Th Fr Sa Su
>   1  2  3  4  5  6  <-- week 0
>7  8  9 10 11 12 13  <-- week 1
>   14 15 16 17 18 19 20  <-- week 2
>   21 22 23 24 25 26 27
>   28 29 30 31
> 
> Since you are reporting your current time as Jan 7 then Dec 31 would
> be last week.  Dec 31 would be week 53.
> 
>   $ env TZ=Australia/Sydney date -d 'last week' -R
>   Mon, 31 Dec 2012 16:59:04 +1100
> 
> And so:
> 
>   $ env TZ=Australia/Sydney date -d 'last week' +%W
>   53
> 
>   $ env TZ=Australia/Sydney date -d 'Dec 31 2012 12:00 +' +%W
>   53
> 
> There are multiple different definitions for week numbers depending
> upon weeks starting on Sunday, starting on Monday, and so forth.
> 
> Also related are:
> 
>   `%U'
>  week number of year, with Sunday as the first day of the week
>  (`00'...`53').  Days in a new year preceding the first Sunday
>  are
>  in week zero.
> 
>   `%V'
>  ISO week number, that is, the week number of year, with Monday
>  as
>  the first day of the week (`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.)
> 
> You might want to look at the strftime man page for an alternate
> description:
> 
>   man 3 strftime
> 
>%U The  week  number of the current year as a decimal
>number, range
>   00 to 53, starting with the first Sunday as  the  first
>day  of
>   week 01.  See also %V and %W.
> 
>%V The  ISO 8601  week  number (see NOTES) of the current
>year as a
>   decimal number, range 01 to 53, where week 1 is the
>first  week
>   that  has  at least 4 days in the new year.  See also
>   %U and %W.
>   (SU)
> 
>%W The  week  number of the current year as a decimal
>number, range
>   00 to 53, starting with the first Monday as  the  first
>day  of
>   week 01.
> 
>ISO 8601 Week Dates
>%G, %g, and %V yield values calculated from the week-based
>year defined
>by the ISO 8601 standard.  In this system, weeks start on a
>Monday, and
>are numbered from 01, for the first week, up to 52 or 53, for
>the  last
>week.  Week 1 is the first week where four or more days fall
>within the
>new year (or, synonymously, week 01 is: the first week of the
>year that
>contains  a  Thursday;  or,  the  week that has 4 January in
>it).  When
>three of fewer days of the first calendar week of  the  new
> year  fall
>within that year, then the ISO 8601 week-based system counts
>those days
>as part of week 53 of the preceding year.  For example, 1
>January  2010
>is a Friday, meaning that just three days of that calendar
>week fall in
>2010.  Thus, the ISO 8601 week-based system considers these
>days to  be
>part  of  week 53 (%V) of the year 2009 (%G) ; week 01 of ISO
>8601 year
>2010 starts on Monday, 4 January 2010.
> 
> Perhaps you are looking for the ISO week date %V?  And if just doing
> calculations I suggest using UTC.
> 
>   $ date -u -d 'Dec 31 2012 12:00 +' +%V
>   01
> 
> The 'ncal' program provides a useful but unusual way to display the
> ISO week numbers:
> 
>   $ ncal -A 1 -w 12 2012
>   December 2012 January 2013
>   Su 2  9 16 23 30 6 13 20 27
>   Mo 3 10 17 24 31 7 14 21 28
>   Tu 4 11 18 25 1  8 15 22 29
>   We 5 12 19 26 2  9 16 23 30
>   Th 6 13 20 27 3 10 17 24 31
>   Fr 7 14 21 28 4 11 18 25
>   Sa  1  8 15 22 29 5 12 19 26
>  48 49 50 51 52  1  1  2  3  4  5
> 
> You should also read the FAQ:
> 
>   
> http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e
> 
> No one is ever happy with week numbers.
> 
> Bob
> 

Bob, many thanks for in depth explanation! Please close this is not a bug.

-- 
Tomas Dabašinskas | Engineering Content Services | Red Hat Asia Pacific
☺: tomas  | ☎: +61(0)7 3514 8204 | ✉: to...@redhat.com

bug#17161: Acknowledgement (Bug in date arithmetic of date)

[Marc R.J. Brevoort]

Additional information -

The behaviour occurs in GNU coreutils 7.4. Version 8.5 appears to work 
correctly so this may be a dupe.

bug#6132: bug in date: --rfc-3339=TIMESPEC option doesn't print 'T'

[F. Alexander Njemz]

Hi,

as evidenced here [1] the slightly ambiguous wording in the RFC 3339 [2]
seems to be the reason that the date utility using the 
--rfc3339=TIMESPEC switch formats the date with a space instead of a 'T'.


I was confused as well, so I took the liberty to mail the authors of the
RFC in question. I attached the reply from Mr. Klyne.

There is also a patch attached.


Regards,

F. Alexander Njemz




[1] http://lists.gnu.org/archive/html/bug-coreutils/2006-05/msg00014.html

[2] http://www.ietf.org/rfc/rfc3339.txt

--- Begin Message ---

In short: "yes"

Per section 5.5, the intent in this draft was to specify a timestamp format 
using elements from and compatible with 8601, but eliminating as far as 
reasonable any variations that could make timestamp data harder to process. 
This includes making the 'T' mandatory in date+time values.


#g
--

F. Alexander Njemz wrote:

Dear Sirs,

there seems to be some confusion about the interpretation of the 
following passages

of RFC 3339:
in section 5.6:
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.
and in Appendix A:
ISO 8601 states that the "T" may be omitted under some
circumstances.  This grammar requires the "T" to avoid ambiguity.

So, what I would like to ask is if the "T" is mandatory for RFC 3339 
conformance or not?


Thanks in advance.

Regards,

F. Alexander Njemz




--- End Message ---
>From ad52a8983b8bc3c5a1808e9ed2bec9930e9c8210 Mon Sep 17 00:00:00 2001
From: F. Alexander Njemz 
Date: Fri, 7 May 2010 10:55:36 +0200
Subject: [PATCH] date: fixed rfc-3339 format strings

* src/date.c (main): Insert a 'T' between date and time in rfc-3339
format strings as specified by the rfc.
---
 src/date.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/date.c b/src/date.c
index c39adb1..daeaf0d 100644
--- a/src/date.c
+++ b/src/date.c
@@ -343,8 +343,8 @@ main (int argc, char **argv)
 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,
-- 
1.7.0.4

bug#6132: bug in date: --rfc-3339=TIMESPEC option doesn't print 'T'

[Eric Blake]

On 05/07/2010 07:25 AM, F. Alexander Njemz wrote:
> Hi,
> 
> as evidenced here [1] the slightly ambiguous wording in the RFC 3339 [2]
> seems to be the reason that the date utility using the
> --rfc3339=TIMESPEC switch formats the date with a space instead of a 'T'.
> 
> I was confused as well, so I took the liberty to mail the authors of the
> RFC in question. I attached the reply from Mr. Klyne.
> 
> There is also a patch attached.

Thanks for the report, and also for the patch.  However, I'm reluctant
to create a date format that we cannot then reparse.  So before we apply
this patch, we would first need a patch to gnulib's getdate.y that
allows parsing of an rfc3339 style with a 'T' instead of a space.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

bug#6132: bug in date: --rfc-3339=TIMESPEC option doesn't print 'T'

[F. Alexander Njemz]

On 05/07/2010 05:55 PM, Eric Blake wrote:

On 05/07/2010 07:25 AM, F. Alexander Njemz wrote:
   

Hi,

as evidenced here [1] the slightly ambiguous wording in the RFC 3339 [2]
seems to be the reason that the date utility using the
--rfc3339=TIMESPEC switch formats the date with a space instead of a 'T'.

I was confused as well, so I took the liberty to mail the authors of the
RFC in question. I attached the reply from Mr. Klyne.

There is also a patch attached.
 

Thanks for the report, and also for the patch.  However, I'm reluctant
to create a date format that we cannot then reparse.  So before we apply
this patch, we would first need a patch to gnulib's getdate.y that
allows parsing of an rfc3339 style with a 'T' instead of a space.

   



Hi Mr. Blake, hi mailing list,

I'm looking into getdate.y.
Mr. Newman has replied as well (see attachment).

I don't think Mr. Newman's mail applies to the date command, since IMHO 
date returns a

single field.

What do you think?

Regards,

F. Alexander Njemz
--- Begin Message ---
If you're representing the date and time as a single field, then the "T" is 
necessary for compliance with RFC 3339 as Graham stated.


If you're using a multi-field representation where date and time are 
separate fields, then the field delimiter depends on your higher level 
field-encoding format.  In this case you would reference the full-date and 
full-time syntax elements from section 5.6 separately (instead of 
referencing the date-time syntax) and would be compliant with RFC 3339 if 
you were compliant with those elements.


- Chris

--On May 7, 2010 13:05:41 +0100 Graham Klyne  wrote:

In short: "yes"

Per section 5.5, the intent in this draft was to specify a timestamp
format using elements from and compatible with 8601, but eliminating as
far as reasonable any variations that could make timestamp data harder to
process. This includes making the 'T' mandatory in date+time values.

# g
--

F. Alexander Njemz wrote:

Dear Sirs,

there seems to be some confusion about the interpretation of the
following passages
of RFC 3339:
in section 5.6:
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.
and in Appendix A:
ISO 8601 states that the "T" may be omitted under some
circumstances.  This grammar requires the "T" to avoid ambiguity.

So, what I would like to ask is if the "T" is mandatory for RFC 3339
conformance or not?

Thanks in advance.

Regards,

F. Alexander Njemz


--- End Message ---

bug#17161: closed (Re: bug#17161: Bug in date arithmetic of date)

[Marc R.J. Brevoort]

Hello,

As a heads-up, the explanation that this is due to time zone+locale doesn't 
make sense:

mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -1 day" +"%Y-%m-%d 
%H:%M:%S"

2014-03-12 13:34:56
mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -2 days" +"%Y-%m-%d 
%H:%M:%S"

2014-03-12 14:34:56
mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -3 days" +"%Y-%m-%d 
%H:%M:%S"

2014-03-12 15:34:56

The more days I subtract, the more hours are added. If this were a time 
zone issue, the amount of hours added would be constant but the 
resulting date would not.


Best,
Marc

On Tue, 1 Apr 2014, GNU bug Tracking System wrote:


Your bug report

#17161: Bug in date arithmetic of date

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 17...@debbugs.gnu.org.

--
17161: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17161
GNU Bug Tracking System
Contact help-debb...@gnu.org with problems

bug#17161: closed (Re: bug#17161: Bug in date arithmetic of date)

[Eric Blake]

reopen 17161
thanks

On 04/02/2014 02:17 AM, Marc R.J. Brevoort wrote:
> Hello,
> 
> As a heads-up, the explanation that this is due to time zone+locale
> doesn't make sense:
> 
> mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -1 day" +"%Y-%m-%d
> %H:%M:%S"
> 2014-03-12 13:34:56
> mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -2 days"
> +"%Y-%m-%d %H:%M:%S"
> 2014-03-12 14:34:56
> mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -3 days"
> +"%Y-%m-%d %H:%M:%S"
> 2014-03-12 15:34:56
> 
> The more days I subtract, the more hours are added. If this were a time
> zone issue, the amount of hours added would be constant but the
> resulting date would not.

Thanks for persisting.  I was able to reproduce using coreutils.git, and
I can explain what's happening.  Date is parsing this as:

"(2014-03-11 12:34:56 -3) (days)"

that is, -3 is being treated as the timezone, since it occurs next to
the hour specification; then treating "days" as "+1 day" or "+24 hours".

Watch what happens when you reorder the line to force a different parse:

$ src/date --utc -d "-3 days 2014-03-11 12:34:56" +"%Y-%m-%d %H:%M:%S"
2014-03-08 12:34:56

It does indeed seem awkward that date is not parsing this as:

"(2014-03-11 12:34:56) (-3 days)"

but fixing that will require tweaks to the getdate.y parser in gnulib.
I've reopened the bug to track the issue with awkward precedence in the
parser.

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



signature.asc
Description: OpenPGP digital signature

bug#17161: closed (Re: bug#17161: Bug in date arithmetic of date)

[Marc R.J. Brevoort]

Hi,

Yes, I've come to the same conclusion (i.e. the numeric value in "+3 days" 
or "-2 days" being treated as time zone). The 8.5 coreutils I tested on 
is in a different time zone so it is possible it doesn't exhibit the same 
behavior because of that, and as such I can't actually tell whether the

behavior is actually resolved in coreutils 8.5.

I confirm that if I type,

mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 0 -1 day" +"%Y-%m-%d
 %H:%M:%S"

(i.e. using "0" as time zone), this gives the expected output,

2014-03-10 12:34:56

Best,
Marc


On Wed, 2 Apr 2014, Eric Blake wrote:


reopen 17161
thanks

On 04/02/2014 02:17 AM, Marc R.J. Brevoort wrote:

Hello,

As a heads-up, the explanation that this is due to time zone+locale
doesn't make sense:

mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -1 day" +"%Y-%m-%d
%H:%M:%S"
2014-03-12 13:34:56
mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -2 days"
+"%Y-%m-%d %H:%M:%S"
2014-03-12 14:34:56
mrjb@THE-D-MRJB:~$ date --utc -d "2014-03-11 12:34:56 -3 days"
+"%Y-%m-%d %H:%M:%S"
2014-03-12 15:34:56

The more days I subtract, the more hours are added. If this were a time
zone issue, the amount of hours added would be constant but the
resulting date would not.


Thanks for persisting.  I was able to reproduce using coreutils.git, and
I can explain what's happening.  Date is parsing this as:

"(2014-03-11 12:34:56 -3) (days)"

that is, -3 is being treated as the timezone, since it occurs next to
the hour specification; then treating "days" as "+1 day" or "+24 hours".

Watch what happens when you reorder the line to force a different parse:

$ src/date --utc -d "-3 days 2014-03-11 12:34:56" +"%Y-%m-%d %H:%M:%S"
2014-03-08 12:34:56

It does indeed seem awkward that date is not parsing this as:

"(2014-03-11 12:34:56) (-3 days)"

but fixing that will require tweaks to the getdate.y parser in gnulib.
I've reopened the bug to track the issue with awkward precedence in the
parser.

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

bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable

[Eiríkur Hjartarson via GNU coreutils Bug Reports]

Hi,

I'm on Fedora-38 GNU/Linux and the version string of 'date' is "date 
(GNU coreutils) 9.1".


$ ls -l /etc/localtime
lrwxrwxrwx. 1 root root 40 jan 11  2022 /etc/localtime -> 
../usr/share/zoneinfo/Atlantic/Reykjavik


Now the "bug":

$ TZ=Europe/Riga date --iso-8601=minutes -d "2024-01-01T00:00-05:00"
2024-01-01T07:00+02:00

$ TZ=UTC+2 date --iso-8601=minutes -d "2024-01-01T00:00-05:00"
2023-01-01T03:00-02:00

That is: the first command gives me the time and date in Riga when it's
midnight at new year's eve in New York.

The second command should do the same but instead gives the time in 
Godthab Greenland.


$ TZ=America/Godthab date -d "2024-01-01T00:00-05:00" --iso-8601=minutes
2024-01-01T03:00-02:00

It seems to me that the sign in the timezone variable could be simply 
reversed.


Regards,
--
Eiríkur

bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable

[Andreas Schwab]

On Mai 07 2023, Eiríkur Hjartarson via GNU coreutils Bug Reports wrote:

> Now the "bug":

It's not a bug.

> $ TZ=Europe/Riga date --iso-8601=minutes -d "2024-01-01T00:00-05:00"
> 2024-01-01T07:00+02:00
>
> $ TZ=UTC+2 date --iso-8601=minutes -d "2024-01-01T00:00-05:00"
> 2023-01-01T03:00-02:00
>
> That is: the first command gives me the time and date in Riga when it's
> midnight at new year's eve in New York.
>
> The second command should do the same but instead gives the time in
> Godthab Greenland.

That's not how TZ works.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html
says about the offset:

Indicates the value added to the local time to arrive at Coordinated
Universal Time. ...  If preceded by a '-', the timezone shall be
east of the Prime Meridian; otherwise, it shall be west (which may
be indicated by an optional preceding '+' ).

Thus TZ=UTC+2 means two hours before UTC.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#63349: Bug in date when using UTC/GMT timeszones in the TZ variable

[Paul Eggert]

On 5/7/23 07:52, Andreas Schwab wrote:

Thus TZ=UTC+2 means two hours before UTC.



Yes, and this mistake seems to be common enough that I installed the 
attached patch into Gnulib, so that it'll propagate into the Coreutils 
manual, which should help people who read the 'date' documentation 
(admittedly only a subset of 'date' users).
From 9f205ff9624b8e10b4331432c59bc732b8c1a7fe Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sun, 7 May 2023 09:28:57 -0700
Subject: [PATCH] Warn against bogus TZ settings

* doc/parse-datetime.texi (Specifying time zone rules):
Warn against TZ="UTC=5".
---
 ChangeLog   | 6 ++
 doc/parse-datetime.texi | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/ChangeLog b/ChangeLog
index 06ff163e0e..823d32b66f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2023-05-07  Paul Eggert  
+
+	Warn against bogus TZ settings
+	* doc/parse-datetime.texi (Specifying time zone rules):
+	Warn against TZ="UTC=5".
+
 2023-05-05  Bruno Haible  
 
 	dirfd: Add tests.
diff --git a/doc/parse-datetime.texi b/doc/parse-datetime.texi
index d54d7660c8..ec0160da8e 100644
--- a/doc/parse-datetime.texi
+++ b/doc/parse-datetime.texi
@@ -574,6 +574,9 @@ This example uses the somewhat-confusing POSIX convention for rules.
 and the time zone is 7 hours west of Greenwich, and
 @samp{TZ="<+0530>-5:30"} says that the time zone abbreviation is @samp{+0530}
 and the time zone is 5 hours 30 minutes east of Greenwich.
+(One should never use a setting like @samp{TZ="UTC-5"}, since
+this would incorrectly imply that local time is five hours east of
+Greenwich and the time zone is called ``UTC''.)
 Although trickier POSIX @env{TZ} settings like
 @samp{TZ="<-05>+5<-04>,M3.2.0/2,M11.1.0/2"} can specify some daylight
 saving regimes, location-based settings like
-- 
2.40.1