bug#60030: Small error in date command

[Pádraig Brady]

tag 60030 notabug
close 60030
stop

On 13/12/2022 02:50, Malin Freeborn wrote:

Hi bug-team,

There's a small error in the date man page. If you search for `%F`
you'll notice the date is summarized as so:

%F full date; like %+4Y-%m-%d

The example shows the `%` sign before the `+`.


This was intentional. '+' is a flag in this context as per:
https://github.com/coreutils/coreutils/commit/2ab2f7a42

cheers,
Pádraig

bug#60030: Small error in date command

[Malin Freeborn]

Hi bug-team,

There's a small error in the date man page. If you search for `%F`
you'll notice the date is summarized as so:

%F full date; like %+4Y-%m-%d

The example shows the `%` sign before the `+`.

Best,
 - Malin

bug#57834: Date Command Anomaly

[Chris Elvidge]

On 23/09/2022 14:03, Bert Wesarg via GNU coreutils Bug Reports wrote:

Dear,

$ TZ=Europe/London date --debug --date="2022/03/27 01:00:00"
date: warning: value 2022 has 4 digits. Assuming /MM/DD
date: parsed date part: (Y-M-D) 2022-03-27
date: parsed time part: 01:00:00
date: input timezone: TZ="Europe/London" environment value
date: using specified time as starting value: '01:00:00'
date: error: invalid date/time value:
date: user provided time: '(Y-M-D) 2022-03-27 01:00:00'
date:normalized time: '(Y-M-D) 2022-03-27 02:00:00'
date: --
date:  possible reasons:
date:non-existing due to daylight-saving time;
date:numeric values overflow;
date:missing timezone
date: invalid date ‘2022/03/27 01:00:00’

Best
Bert

On Thu, Sep 15, 2022 at 5:21 PM Martin Hughes via GNU coreutils Bug
Reports  wrote:



Dear Sir,
I have stumbled across this anomaly whilst processing a series of dates.
I have not found any other legal date combination that generates this
error. Perl time facilities seem to be affected by this too.

mjh@carnaby:~> date --date="2022/03/27 00:00:00"
Sun 27 Mar 00:00:00 GMT 2022

mjh@carnaby:~> date --date="2022/03/27 01:00:00"
date: invalid date ‘2022/03/27 01:00:00’

mjh@carnaby:~> date --date="2022/03/27 02:00:00"
Sun 27 Mar 02:00:00 BST 2022

The version of date is:
mjh@carnaby:~> date --version
date (GNU coreutils) 8.29
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David MacKenzie.

The operating system is opensuse leap 15.2:
Linux version 5.3.18-lp152.106-default (geeko@buildhost) (gcc version
7.5.0 (SUSE Linux)) #1 SMP Mon Nov 22 08:38:17 UTC 2021 (52078fe)

Martin Hughes







A bit late to the party weren't you?
Martin acknowledged it was GMT/BST transition, on 15th September.

--

Chris Elvidge

bug#57834: Date Command Anomaly

[Bert Wesarg via GNU coreutils Bug Reports]

Dear,

$ TZ=Europe/London date --debug --date="2022/03/27 01:00:00"
date: warning: value 2022 has 4 digits. Assuming /MM/DD
date: parsed date part: (Y-M-D) 2022-03-27
date: parsed time part: 01:00:00
date: input timezone: TZ="Europe/London" environment value
date: using specified time as starting value: '01:00:00'
date: error: invalid date/time value:
date: user provided time: '(Y-M-D) 2022-03-27 01:00:00'
date:normalized time: '(Y-M-D) 2022-03-27 02:00:00'
date: --
date:  possible reasons:
date:non-existing due to daylight-saving time;
date:numeric values overflow;
date:missing timezone
date: invalid date ‘2022/03/27 01:00:00’

Best
Bert

On Thu, Sep 15, 2022 at 5:21 PM Martin Hughes via GNU coreutils Bug
Reports  wrote:
>
>
> Dear Sir,
> I have stumbled across this anomaly whilst processing a series of dates.
> I have not found any other legal date combination that generates this
> error. Perl time facilities seem to be affected by this too.
>
> mjh@carnaby:~> date --date="2022/03/27 00:00:00"
> Sun 27 Mar 00:00:00 GMT 2022
>
> mjh@carnaby:~> date --date="2022/03/27 01:00:00"
> date: invalid date ‘2022/03/27 01:00:00’
>
> mjh@carnaby:~> date --date="2022/03/27 02:00:00"
> Sun 27 Mar 02:00:00 BST 2022
>
> The version of date is:
> mjh@carnaby:~> date --version
> date (GNU coreutils) 8.29
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> .
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Written by David MacKenzie.
>
> The operating system is opensuse leap 15.2:
> Linux version 5.3.18-lp152.106-default (geeko@buildhost) (gcc version
> 7.5.0 (SUSE Linux)) #1 SMP Mon Nov 22 08:38:17 UTC 2021 (52078fe)
>
> Martin Hughes

bug#57834: Date Command Anomaly - Forget it. My Oversite

[Martin Hughes via GNU coreutils Bug Reports]

Sorry, my oversite,

It was the transition from Greenwich Mean Time to British Summer time 
27th March.


Martin Hughes

bug#57834: Date Command Anomaly

[Martin Hughes via GNU coreutils Bug Reports]

Dear Sir,
I have stumbled across this anomaly whilst processing a series of dates. 
I have not found any other legal date combination that generates this 
error. Perl time facilities seem to be affected by this too.


mjh@carnaby:~> date --date="2022/03/27 00:00:00"
Sun 27 Mar 00:00:00 GMT 2022

mjh@carnaby:~> date --date="2022/03/27 01:00:00"
date: invalid date ‘2022/03/27 01:00:00’

mjh@carnaby:~> date --date="2022/03/27 02:00:00"
Sun 27 Mar 02:00:00 BST 2022

The version of date is:
mjh@carnaby:~> date --version
date (GNU coreutils) 8.29
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
.

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David MacKenzie.

The operating system is opensuse leap 15.2:
Linux version 5.3.18-lp152.106-default (geeko@buildhost) (gcc version 
7.5.0 (SUSE Linux)) #1 SMP Mon Nov 22 08:38:17 UTC 2021 (52078fe)


Martin Hughes

bug#50115: date command arithmetic involving the epoch produces "invalid date"

[Paul Eggert]

Thanks for the bug report. I installed the attached patches to Gnulib 
and to Coreutils, and the fix should be in the next Coreutils release.From aa0d1e7800903f2d75432d78aa64a0e9770e83f2 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 5 Feb 2022 11:05:44 -0800
Subject: [PATCH] parse-datetime: allow calculations to yield -1

Problem reported by Jeremy Cantrell .
* lib/parse-datetime.y (parse_datetime_body): When calling mktime,
use an unmodifed and negative tm_wday or tm_yday to detect an error,
as a (time_t) -1 return value is valid on most hosts.
* tests/test-parse-datetime.c (main): Add a test for the bug.
---
 ChangeLog   |  9 +
 lib/parse-datetime.y| 22 +++---
 tests/test-parse-datetime.c |  8 
 3 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 5445802ea2..18dcb3fe3f 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2022-02-05  Paul Eggert  
+
+	parse-datetime: allow calculations to yield -1
+	Problem reported by Jeremy Cantrell .
+	* lib/parse-datetime.y (parse_datetime_body): When calling mktime,
+	use an unmodifed and negative tm_wday or tm_yday to detect an error,
+	as a (time_t) -1 return value is valid on most hosts.
+	* tests/test-parse-datetime.c (main): Add a test for the bug.
+
 2022-02-04  Paul Eggert  
 
 	userspec: help fix GNU ‘id’ incompatibility
diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
index c40fdcef7f..9fc14c9d46 100644
--- a/lib/parse-datetime.y
+++ b/lib/parse-datetime.y
@@ -2076,21 +2076,20 @@ parse_datetime_body (struct timespec *result, char const *p,
   if (pc.days_seen && ! pc.dates_seen)
 {
   intmax_t dayincr;
-  if (INT_MULTIPLY_WRAPV ((pc.day_ordinal
-   - (0 < pc.day_ordinal
-  && tm.tm_wday != pc.day_number)),
-  7, )
-  || INT_ADD_WRAPV ((pc.day_number - tm.tm_wday + 7) % 7,
-dayincr, )
-  || INT_ADD_WRAPV (dayincr, tm.tm_mday, _mday))
-Start = -1;
-  else
+  tm.tm_yday = -1;
+  if (! (INT_MULTIPLY_WRAPV ((pc.day_ordinal
+  - (0 < pc.day_ordinal
+ && tm.tm_wday != pc.day_number)),
+ 7, )
+ || INT_ADD_WRAPV ((pc.day_number - tm.tm_wday + 7) % 7,
+   dayincr, )
+ || INT_ADD_WRAPV (dayincr, tm.tm_mday, _mday)))
 {
   tm.tm_isdst = -1;
   Start = mktime_z (tz, );
 }
 
-  if (Start == (time_t) -1)
+  if (tm.tm_yday < 0)
 {
   if (debugging ())
 dbg_printf (_("error: day '%s' "
@@ -2156,8 +2155,9 @@ parse_datetime_body (struct timespec *result, char const *p,
   tm.tm_min = tm0.tm_min;
   tm.tm_sec = tm0.tm_sec;
   tm.tm_isdst = tm0.tm_isdst;
+  tm.tm_wday = -1;
   Start = mktime_z (tz, );
-  if (Start == (time_t) -1)
+  if (tm.tm_wday < 0)
 {
   if (debugging ())
 dbg_printf (_("error: adding relative date resulted "
diff --git a/tests/test-parse-datetime.c b/tests/test-parse-datetime.c
index 059c810cd1..1e7955bc96 100644
--- a/tests/test-parse-datetime.c
+++ b/tests/test-parse-datetime.c
@@ -398,6 +398,14 @@ main (_GL_UNUSED int argc, char **argv)
   ASSERT (result.tv_sec == thur2 + ((i + 3) % 7 - 7) * 24 * 3600);
 }
 
+  p = "1970-12-31T23:59:59+00:00 - 1 year";  /* Bug#50115 */
+  now.tv_sec = -1;
+  now.tv_nsec = 0;
+  ASSERT (parse_datetime (, p, ));
+  LOG (p, now, result);
+  ASSERT (result.tv_sec == now.tv_sec
+  && result.tv_nsec == now.tv_nsec);
+
   p = "THURSDAY UTC+00";  /* The epoch was on Thursday.  */
   now.tv_sec = 0;
   now.tv_nsec = 0;
-- 
2.32.0

From cf6c84989968c5081c683bbef77825fc35e03c9d Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 5 Feb 2022 11:08:45 -0800
Subject: [PATCH 1/2] build: update gnulib submodule to latest

---
 gnulib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnulib b/gnulib
index ff208d546..aa0d1e780 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit ff208d546a26fee39a0191297c11560da74b5dee
+Subproject commit aa0d1e7800903f2d75432d78aa64a0e9770e83f2
-- 
2.32.0

From 8a3dedfef9479c53cd9016139ce00d58a6006ba2 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Sat, 5 Feb 2022 13:46:44 -0800
Subject: [PATCH 2/2] date: test against bug#50115

* tests/misc/date.pl: Add test.
---
 tests/misc/date.pl | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/misc/date.pl b/tests/misc/date.pl
index e9de8e453..ef7080e33 100755
--- a/tests/misc/date.pl
+++ b/tests/misc/date.pl
@@ -301,6 +301,9 @@ my @Tests =
  # 

bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates

[Mike Marchywka]

On Wed, Dec 15, 2021 at 02:09:29PM -0800, Paul Eggert wrote:
> On 12/15/21 12:39, Mike Marchywka wrote:
> > $echo 2000 | date +%Y -f-
> > 2021
> 
> How about this instead? The idea is to avoid
> adding features if they can easily be
> implemented with some other standard utility.
> This way, you can write your shell scripts now
> rather than waiting for a future fix (plus, it
> keeps 'date' simpler).
> 
> echo 2000 | sed 's/$/-07-01/' | date +%Y -f-
> 

That is great until the input format is -MM-DD :)
The point of using date was to get all the internal
stuff that deals with ambiguous formats and probably
a lot of other people do that too.  
The info documentation does point out how ambiguous
the human readable dates are. I guess 2000 could also
be ms since epoch. I am calling date from c++
and could just ias easily wrap it in another c++ program
to deal with this but thought it was of more general
interest and I did not want to make another kluge.

Generally I agree with your approach but if date is
going to be a swiss army knife for date conversions
it makes some sense to allow user selection of
ambiguity resolution doesn't it? 

Thanks. 




-- 

mike marchywka
306 charles cox
canton GA 30115
USA, Earth 
marchy...@hotmail.com
404-788-1216
ORCID: -0001-9237-455X

bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates

[Paul Eggert]

On 12/15/21 14:24, Mike Marchywka wrote:


if date is
going to be a swiss army knife for date conversions
it makes some sense to allow user selection of
ambiguity resolution doesn't it?


There are thousands of possible data conversions and I'm not sure we 
want to head down the road of trying to handle them all.


That being said, this particular conversion might be worth the trouble. 
However, 'date' uses the same date parser that a lot of other GNU 
programs do. Surely if there's a change to be made to date parsing it 
should be made there, not just to 'date', so that all the other programs 
can use the new functionality.

bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates

[Paul Eggert]

On 12/15/21 12:39, Mike Marchywka wrote:

$echo 2000 | date +%Y -f-
2021


How about this instead? The idea is to avoid adding features if they can 
easily be implemented with some other standard utility. This way, you 
can write your shell scripts now rather than waiting for a future fix 
(plus, it keeps 'date' simpler).


echo 2000 | sed 's/$/-07-01/' | date +%Y -f-

bug#52525: wanted to add option to date command to handle pure numeric input in varying ways and output for invalid dates

[Mike Marchywka]

I'm trying to implement the options shown below. I downloaded the coreutils 
source
for my distro and don't expect a problem compling and implementing it.
However, is there any interest in adding similar functions to the main code?

I would imagine something like,

date  --option=four-digits-are-,invalid-output-blank-line 

My immediate concern is getting this to take the input as a year rather than 
HHMM and
it would be easier to make date more versatile than put logic around it,

$echo 2000 | date +%Y -f-
2021

not sure if anyone else would want that.

Thanks. 



 Mike Marchywka 
306 Charles Cox Drive 
Canton, GA 30115
470-758-0799
404-788-1216 





From: Mike Marchywka
Sent: Wednesday, December 15, 2021 2:08 PM
To: coordina...@translationproject.org
Subject: the ubuntu "date" command info pointed me to you, question on 
modification

I wanted to add an option to the linux date command to
deal with pure number date stings - allowing for a 4 digit number
to be a year instead of HHMM - which should be easy
for me to do but I wanted to see how it integrates.
Also, I wanted an output option, that I could write, to
send an invalid message to stdout instead of stderr.

How should I proceed?

Thanks.


 Mike Marchywka
306 Charles Cox Drive
Canton, GA 30115
470-758-0799
404-788-1216

bug#50115: date command arithmetic involving the epoch produces "invalid date"

[Jeremy Cantrell]

Using `date --utc --date="..."` with a date specification that
decrements by years that should result in epoch=0
(1969-12-31T23:59:59+00:00) produces an "invalid date" error message.

The following commands should illustrate the problem:

Notice that the only difference between the starting dates is 1 second.
```sh
$ date -u -d "1970-12-31T23:59:59+00:00 - 1 year"
date: invalid date ‘1970-12-31T23:59:59+00:00 - 1 year’
$ date -u -d "1970-12-31T23:59:58+00:00 - 1 year"
Wed Dec 31 11:59:58 PM UTC 1969
```

The dates are only considered invalid if they fall on epoch=0:
```sh
$ date -u -d "1971-12-31T23:59:59+00:00 - 2 year"
date: invalid date ‘1971-12-31T23:59:59+00:00 - 2 year’
$ date -u -d "1972-12-31T23:59:59+00:00 - 3 year"
date: invalid date ‘1972-12-31T23:59:59+00:00 - 3 year’
```

Going the other direction seems to work:
```sh
$ date -u -d "1969-01-01T00:00:00+00:00 + 1 year"
Thu Jan  1 12:00:00 AM UTC 1970
```

It only seems to error when decrementing by years:
```sh
 date -u -d "1970-01-01T00:00:01+00:00 - 1 second"
Thu Jan  1 12:00:00 AM UTC 1970
```

It only seems to error when using --utc, because the following works
(my time zone is America/Chicago):
```sh
$ date -d "Wed Dec 31 06:00:00 PM CST 1970 - 1 year" +%s
0
```

bug#44240: coreutils 8.30-3ubuntu2 "date" command doesn't like one specific date: 2020-09-06

[Philip Rowlands]

On Mon, 26 Oct 2020, at 15:14, Leo Wandersleb wrote:
> for some reason I get an error with one specific date but not with others:
> 
> $ for i in 08 09 10; do for j in 5 6 7; do d="2020-$i-0$j"; echo $d $( date
> -d"$d" ); done; done
> 2020-08-05 Wed 05 Aug 2020 12:00:00 AM -04
> 2020-08-06 Thu 06 Aug 2020 12:00:00 AM -04
> 2020-08-07 Fri 07 Aug 2020 12:00:00 AM -04
> 2020-09-05 Sat 05 Sep 2020 12:00:00 AM -04
> date: invalid date ‘2020-09-06’
> 2020-09-06
> 2020-09-07 Mon 07 Sep 2020 12:00:00 AM -03

The clue is the change in timezone offset from -04 to -03. The only location I 
could find which switched on 2020-09-06 was Chile, so we can reproduce the 
problem with:

$ TZ=Chile/Continental date --debug -d 2020-09-06
date: parsed date part: (Y-M-D) 2020-09-06
date: input timezone: TZ="Chile/Continental" environment value
date: warning: using midnight as starting time: 00:00:00
date: error: invalid date/time value:
date: user provided time: '(Y-M-D) 2020-09-06 00:00:00'
date:normalized time: '(Y-M-D) 2020-09-06 01:00:00'
date: --
date:  possible reasons:
date:non-existing due to daylight-saving time;
date:numeric values overflow;
date:missing timezone
date: invalid date ‘2020-09-06’

Notice that, in Chile's DST rules, the time jumps from 23:59:59 to 01:00:00:
$ zdump -v Chile/Continental | grep 2020
Chile/Continental  Sun Apr  5 02:59:59 2020 UT = Sat Apr  4 23:59:59 2020 -03 
isdst=1 gmtoff=-10800
Chile/Continental  Sun Apr  5 03:00:00 2020 UT = Sat Apr  4 23:00:00 2020 -04 
isdst=0 gmtoff=-14400
Chile/Continental  Sun Sep  6 03:59:59 2020 UT = Sat Sep  5 23:59:59 2020 -04 
isdst=0 gmtoff=-14400
Chile/Continental  Sun Sep  6 04:00:00 2020 UT = Sun Sep  6 01:00:00 2020 -03 
isdst=1 gmtoff=-10800

Therefore there is no valid time "00:00:00", and this is the "non-existing due 
to daylight-saving time" case which date --debug reports.

This is an FAQ, which often crops up twice per year:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e


Cheers,
Phil

bug#44240: coreutils 8.30-3ubuntu2 "date" command doesn't like one specific date: 2020-09-06

[Leo Wandersleb]

Hi,

for some reason I get an error with one specific date but not with others:

$ for i in 08 09 10; do for j in 5 6 7; do d="2020-$i-0$j"; echo $d $( date
-d"$d" ); done; done
2020-08-05 Wed 05 Aug 2020 12:00:00 AM -04
2020-08-06 Thu 06 Aug 2020 12:00:00 AM -04
2020-08-07 Fri 07 Aug 2020 12:00:00 AM -04
2020-09-05 Sat 05 Sep 2020 12:00:00 AM -04
date: invalid date ‘2020-09-06’
2020-09-06
2020-09-07 Mon 07 Sep 2020 12:00:00 AM -03
2020-10-05 Mon 05 Oct 2020 12:00:00 AM -03
2020-10-06 Tue 06 Oct 2020 12:00:00 AM -03
2020-10-07 Wed 07 Oct 2020 12:00:00 AM -03

Regards,

Leo Wandersleb

bug#40958: date command give current time zone regardless of seconds since epoch requested.

[Bob Proulx]

tag 40958 + notabug
close 40958
thanks

GNAT via GNU coreutils Bug Reports wrote:
> I am going to hazard a guess and say this is the expected behaviour,
> but I cannot find anything though goog.

The FAQ gives the recipe to figure these types of problems out.

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

And for the timezone and date in question.

  zdump -v Europe/London | grep 1970
  ...no output...

That would be a little confusing.  So let's look at it with a pager
such as less.  Browse and find the years of interest.

  zdump -v Europe/London | less
  ...
  Europe/London  Sun Feb 18 01:59:59 1968 UT = Sun Feb 18 01:59:59 1968 GMT 
isdst=0 gmtoff=0
  Europe/London  Sun Feb 18 02:00:00 1968 UT = Sun Feb 18 03:00:00 1968 BST 
isdst=1 gmtoff=3600
  Europe/London  Sat Oct 26 22:59:59 1968 UT = Sat Oct 26 23:59:59 1968 BST 
isdst=1 gmtoff=3600
  Europe/London  Sat Oct 26 23:00:00 1968 UT = Sun Oct 27 00:00:00 1968 BST 
isdst=0 gmtoff=3600
  Europe/London  Sun Oct 31 01:59:59 1971 UT = Sun Oct 31 02:59:59 1971 BST 
isdst=0 gmtoff=3600
  Europe/London  Sun Oct 31 02:00:00 1971 UT = Sun Oct 31 02:00:00 1971 GMT 
isdst=0 gmtoff=0
  ...

And therefore it is of course as Andreas Schwab wrote.  "This took
place between 27 October 1968 and 31 October 1971, ..."  An
interesting footnote of history!

The date command uses the Time Zone Database for this information.
The database is typically updated by the operating system software
distribution upon which GNU date is run.  The The source of the
database is available here.

  https://www.iana.org/time-zones

GNU date is operating upon the data from that database.  That database
is updated often as it is a global compilation of every act of
governance and must be updated as the timezone rules are updated.  In
the Debian and derivative software distributions I know this is
packaged in the 'tzdata' package.

> The date command has a number of switches, one of which is -d where you give 
> it the number of seconds since epoch, as in "date -d@1234" or "date --date 
> @1234".
> 
> Additionally, you can get it to return as any string you want to, as in "date 
> -d@1234 "+%c %z %Z"
> 
> Both return "Thu Jan  1 01:20:34 BST 1970" or "Thu Jan  1 01:20:34 +0100 BST 
> 1970" for the UK.
> 
> /etc/localtime is set to /usr/share/zoneinfo/Europe/London.
> 
> That's wrong, it should give "Thu Jan  1 00:20:34 1970 + GMT".
> 
> After all, in January, the UK is not in daylight saving time at the beginning 
> of January.

And yet there it was!  By an Act of Governance daylight saving time
was in effect at that time!  No one is safe when the government is in
session. :-)

> It therefore gives you the current daylight saving time status,
> rather than what it should be at the time requested.
> 
> I assume currently, this will give erroneous results for any
> requests in daylight saving.

Because date appears to be operating correctly I am closing this bug
ticket.  But please we welcome that any discussion may continue in the
bug ticket.

Bob

bug#40958: date command give current time zone regardless of seconds since epoch requested.

[Andreas Schwab]

>From :

A further inquiry during 1966–1967 led the government of Harold
Wilson to introduce the British Standard Time experiment, with
Britain remaining on GMT+1 throughout the year. This took place
between 27 October 1968 and 31 October 1971, when there was a
reversion to the previous arrangement.

Andreas.

-- 
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#40220: date command set linux epoch time failed

[Paul Eggert]

On 3/29/20 9:32 PM, Bob Proulx wrote:

Both calls from GNU date are returning EINVAL.  Those are Linux kernel
system calls.  Those Linux kernel system calls are using
CLOCK_MONOTONIC.


OK, I think I understand now. For some reason Linux prohibits you from setting 
CLOCK_REALTIME to a value less than what CLOCK_MONOTONIC would report. I don't 
know why Linux has this restriction - it violates POSIX as near as I can tell - 
but at any rate as you say it's a problem with the Linux kernel, not with GNU 
'date'.

bug#40220: date command set linux epoch time failed

[Bob Proulx]

Paul Eggert wrote:
> Bob Proulx wrote:
> > By reading the documentation for CLOCK_MONOTONIC in clock_gettime(2):
> 
> GNU 'date' doesn't use CLOCK_MONOTONIC, so why is CLOCK_MONOTONIC relevant
> to this bug report?

GNU date uses clock_settime() and settimeofday() on my Debian system.
Let me repeat the strace snippet from my previous message which shows this.

  TZ=UTC strace -o /tmp/out -v date -s "1970-01-01 00:00:00"

  ...
  clock_settime(CLOCK_REALTIME, {tv_sec=0, tv_nsec=0}) = -1 EINVAL (Invalid 
argument)
  settimeofday({tv_sec=0, tv_usec=0}, NULL) = -1 EINVAL (Invalid argument)
  ...

Both calls from GNU date are returning EINVAL.  Those are Linux kernel
system calls.  Those Linux kernel system calls are using
CLOCK_MONOTONIC.  Therefore GNU date, on Linux systems, is by
association with the Linux kernel, using CLOCK_MONOTONIC.

And the Linux kernel is returning EINVAL.  And according to the
documentation for both clock_settime() and settimeofday() the most
likely reason for the EINVAL is the application of CLOCK_MONOTONIC
preventing it, because that documentation says that one cannot set the
date earlier than the system uptime.  Why this is desirable I have no
idea as it does not seem desirable to me.  But I am just the
messenger, having read that in the documentation looking for the
reason for the EINVAL return.

> Is this some busybox thing? If so, user 'shy' needs to report it to the
> busybox people, not to bug-coreutils.

No.  It is only a busybox thing as much as it is a GNU date thing in
that both are making system calls to the Linux kernel and both are
failing with EINVAL.  The reference to busybox confused me at first
too.  But in the original report it was simply another case of the
same thing.  Which is actually a strong indication that it is not a
bug in either of the frontend implementations but something common to
both.  In this case the kernel is the common part.

This does not appear to be a bug in the sense that it is explicit
behavior.  It is working as the Linux kernel has coded it to behave.
According to the documentation.

If one were to take this anywhere it would be to the Linux kernel
mailing list to discover why they implemented this inconvenient
behavior.

Meanwhile...  Since I am writing this in this thread...  I might
mention to the original poster that if they are testing using old
clock times they might be able to get a good result by using
libfaketime https://github.com/wolfcw/libfaketime which is a user land
strategy for implementing different fake clock times for programs.
Very useful in testing.  And then there would be no need to set the
system time at all.

  $ faketime '1970-01-01 00:00:00 UTC' date -uR
  Thu, 01 Jan 1970 00:00:00 +

Bob

bug#40220: date command set linux epoch time failed

[Paul Eggert]

On 3/28/20 9:12 AM, Bob Proulx wrote:

By reading the documentation for CLOCK_MONOTONIC in clock_gettime(2):


GNU 'date' doesn't use CLOCK_MONOTONIC, so why is CLOCK_MONOTONIC relevant to 
this bug report?


Is this some busybox thing? If so, user 'shy' needs to report it to the busybox 
people, not to bug-coreutils.

bug#40220: date command set linux epoch time failed

[Bob Proulx]

Paul Eggert wrote:
> Bob Proulx wrote:
> > I tested this in a victim system and if I was very quick I was able to
> > log in and set the time to :10 seconds but no earlier.
> 
> Sounds like some sort of atomic-time thing, since UTC and TAI differed by 10
> seconds when they started up in 1972. Perhaps the clock in question uses TAI
> internally?

By reading the documentation for CLOCK_MONOTONIC in clock_gettime(2):

   CLOCK_MONOTONIC
  Clock that cannot be set and represents monotonic time since--as
  described by POSIX--"some unspecified point in the past".  On
  Linux, that point corresponds to the number of seconds that the
  system has been running since it was booted.

  The CLOCK_MONOTONIC clock is not affected by discontinuous jumps
  in the system time (e.g., if the system administrator manually
  changes the clock), but is affected by the incremental
  adjustments performed by adjtime(3) and NTP.  This clock does
  not count time that the system is suspended.


It's the, "On Linux, that point corresponds to the number of seconds
that the system has been running since it was booted." part that seems
to apply here just by the reading of it.  To test this I can reboot a
VM, which boots quickly, and then as soon as I think it is available
by watching the console I can ssh into it as root from another
terminal.  And then in that other terminal logged in as root I try to
execute "date -s '1970-01-01 00:00:00 UTC'" as soon as possible.  I am
never able to do so due to EINVAL.

But if I reboot and repeat the experiment trying to set a few seconds
in time later then if I am quick I can sometimes catch "date -s
'1970-01-01 00:00:10 UTC'" and have it work.  Trying again now I was
able to be quick and get logged in and set in :07 UTC.  But then if I
wait and let seconds tick by and try setting to :10 UTC seconds again
it will fail.  This matches the model described by the documentation
that CLOCK_MONOTONIC is the system uptime and the kernel is not
allowing the clock set to be before the system uptime.

If I wait longer and try setting the date to various times then
experimentally the behavior matches that I cannot set the system time
earlier than the the system uptime.

Personally I can't see an advantage for this behavior.  Because if
someone is doing an experiment and wants to reset the clock to time
zero then I don't see an advantage of blocking that from happening.
However doing so might avoid some accidental settings of the system
clock to an unintended zero time.  Just like rm --preserve-root.  But
how often does that actually happen?  And then I would want to see a
way to do it anyway for the experiment possibilities.  Here reading
the documentation it seems to be a new hard limitation coded into the
Linux kernel that is blocking this.

Bob

bug#40220: date command set linux epoch time failed

[Paul Eggert]

On 3/27/20 11:52 PM, Bob Proulx wrote:

I tested this in a victim system and if I was very quick I was able to
log in and set the time to :10 seconds but no earlier.


Sounds like some sort of atomic-time thing, since UTC and TAI differed by 10 
seconds when they started up in 1972. Perhaps the clock in question uses TAI 
internally?

bug#40220: date command set linux epoch time failed

[Bob Proulx]

tag 40220 + notabug
close 40220
thanks

shy wrote:
> I use command date -s "1970-01-20 00:00:00" to set date, but it
>  failed.  there is error message "date: can't set date: Invalid
>  argument".
>  It's UTC time and no timezone.

This is most likely a limitation of your kernel.  I can recreate this
problem on a Linux 4.9 system for example.

  TZ=UTC strace -o /tmp/out -v date -s "1970-01-01 00:00:00"

  ...
  clock_settime(CLOCK_REALTIME, {tv_sec=0, tv_nsec=0}) = -1 EINVAL (Invalid 
argument)
  settimeofday({tv_sec=0, tv_usec=0}, NULL) = -1 EINVAL (Invalid argument)
  ...

And the documented possible returns of EINVAL for clock_settime().

   EINVAL The clk_id specified is not supported on this system.

   EINVAL (clock_settime()): tp.tv_sec is negative or tp.tv_nsec is
  outside the range [0..999,999,999].

   EINVAL (since Linux 4.3)
  A call to clock_settime() with a clk_id of CLOCK_REALTIME
  attempted to set the time to a value less than the current value
  of the CLOCK_MONOTONIC clock.

And for settimeofday().

   EINVAL (settimeofday()): timezone is invalid.

   EINVAL (settimeofday()): tv.tv_sec is negative or tv.tv_usec is outside
  the range [0..999,999].

   EINVAL (since Linux 4.3)
  (settimeofday()): An attempt was made to set the time to a value
  less than the current value of the CLOCK_MONOTONIC clock (see
  clock_gettime(2)).

   EPERM  The calling process has insufficient privilege to call
  settimeofday(); under Linux the CAP_SYS_TIME capability is
  required.

But this is not a bug in GNU date.  This is likely the effect of
CLOCK_MONOTONIC in the Linux kernel.

   CLOCK_MONOTONIC
  Clock that cannot be set and represents monotonic time since--as
  described by POSIX--"some unspecified point in the past".  On
  Linux, that point corresponds to the number of seconds that the
  system has been running since it was booted.

  The CLOCK_MONOTONIC clock is not affected by discontinuous jumps
  in the system time (e.g., if the system administrator manually
  changes the clock), but is affected by the incremental
  adjustments performed by adjtime(3) and NTP.  This clock does
  not count time that the system is suspended.

I am not familiar with CLOCK_MONOTONIC but reading the documentation
points me to it as being the most likely reason this is not allowing
that time to be set.

I tested this in a victim system and if I was very quick I was able to
log in and set the time to :10 seconds but no earlier.

> I test with stime or settimeofday to set seconds 0, they are all have the 
> problem.
> 1. I use buildroot-2013.05, the busybox is in 1.21.1, the linux kernel is in 
> version 4.4.39.

That multiple frontends, GNU date and busybox date, all have the same
problem speaks that the problem is not with the frontend but with the
kernel handling the system call.

> 3.When set date command, the busybox uses function "stime" to set
> time, I use stime to set time around linux epoch time,
>but the stime seems not work well.
>int ret = 0;
>time_t time = 20;
>ret = stime();
>printf("ret %d %d\r\n",ret, errno);
>perror("stime:");
> and the results are as follows:
> ret -1 22
> stime:: Invalid argument

And also confirmed by your independent test the the problem is not a
bug in GNU date.  Therefore I mark this GNU date bug ticket as closed
for our own accounting.  But please continue to discuss the issue
here.

Bob

bug#40220: date command set linux epoch time failed

[shy]

Hi all:


I use command date -s "1970-01-20 00:00:00" to set date, but it failed.  
there is error message "date: can't set date: Invalid argument".
 It's UTC time and no timezone.


I test with stime or settimeofday to set seconds 0, they are all have the 
problem.


1. I use buildroot-2013.05, the busybox is in 1.21.1, the linux kernel is in 
version 4.4.39.


# date -s "1970-01-20 00:00:00"
Tue Jan 20 00:00:00 UTC 1970
# date -R
Tue, 20 Jan 1970 00:00:03 +
# date -s "1970-01-01 00:00:00"
date: can't set date: Invalid argument
Thu Jan  1 00:00:00 UTC 1970


2. I test in ubuntu version 14.04.1.
shy@ubuntu:/etc$ sudo date -s "2020-03-01 00:00:00"
Sun Mar  1 00:00:00 UTC 2020
shy@ubuntu:/etc$ date -R
Sun, 01 Mar 2020 00:00:03 +

shy@ubuntu:/etc$ sudo date -s "1970-01-01 00:00:00"

date: cannot set date: Invalid argument

Thu Jan  1 00:00:00 UTC 1970

shy@ubuntu:/etc$ uname -a

Linux ubuntu 4.4.0-142-generic #168~14.04.1-Ubuntu SMP Sat Jan 19 11:26:28 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux




3.When set date command, the busybox uses function "stime" to set time, I use 
stime to set time around  linux epoch time,

   but the stime seems not work well.

   int ret = 0;

   time_t time = 20;

   ret = stime();

   printf("ret %d %d\r\n",ret, errno);

   perror("stime:");

and the results are as follows:

ret -1 22

stime:: Invalid argument




Best regards!








 

bug#36383: date command processes timezone differently when doing math

[Assaf Gordon]

tag 36383 notabug
close 36383
stop

Hello,

On Tue, Jun 25, 2019 at 04:10:07PM -0700, Brian Woods wrote:
> When doing a math operation to a date command it appear to process the
> timezone differently.
[...]
>
> #echo $datNow
> 2019-06-25 15:21:34
>
> #date -d "$datNow + 1 minute" "+%Y-%m-%d %H:%M:%S" --debug
> date: parsed date part: (Y-M-D) 2019-06-25
> date: parsed time part: 15:21:34 UTC+01
> date: parsed relative part: +1 minutes
> date: input timezone: parsed date/time string (+01)

Thank you for providing detailed examples with "--debug",
makes things much easier to troubleshoot.

The issue is that a time string (HH:MM:SS) followed by a plus
sign and a number is *always* taken to be a time zone.

Using a value other than 1 will show it more clearly:

  $ date -d "$datNow + 8 minutes" "+%Y-%m-%d %H:%M:%S" --debug
  date: parsed date part: (Y-M-D) 2019-06-25
  date: parsed time part: 15:21:34 UTC+08
  date: parsed relative part: +1 minutes
  date: input timezone: parsed date/time string (+08)

The "+8" part is treated as timezone,
and the remaining text ("minutes") is taken as a one-minute time
adjustment.

One solution is to just remove the plus sign:

  $ date -d "$datNow 8 minutes" "+%Y-%m-%d %H:%M:%S" --debug
  date: parsed date part: (Y-M-D) 2019-06-25
  date: parsed time part: 15:21:34
  date: parsed relative part: +8 minutes
  date: input timezone: system default
  [...]
  2019-06-25 15:29:34

Another is to specify the time zone:

  $ date -d "$datNow +00:00 +8 minutes" "+%Y-%m-%d %H:%M:%S" --debug
  date: parsed date part: (Y-M-D) 2019-06-25
  date: parsed time part: 15:21:34 UTC+00
  date: parsed relative part: +8 minutes
  date: input timezone: parsed date/time string (+00)
  [...]
  2019-06-25 09:29:34


More examples of adjusting time strings are here (your example is similar
to case #1):
https://lists.gnu.org/archive/html/bug-coreutils/2018-10/msg00126.html

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

regards,
 - assaf

bug#36383: date command processes timezone differently when doing math

[Brian Woods]

When doing a math operation to a date command it appear to process the
timezone differently.

The system is Ubuntu 18.04.2 LTS.
Versions: coreutils/bionic,now 8.28-1ubuntu1 amd64 [installed]

#echo $datNow
2019-06-25 15:21:34

#date -d "$datNow " "+%Y-%m-%d %H:%M:%S" --debug
date: parsed date part: (Y-M-D) 2019-06-25
date: parsed time part: 15:21:34
date: input timezone: system default
date: using specified time as starting value: '15:21:34'
date: starting date/time: '(Y-M-D) 2019-06-25 15:21:34'
date: '(Y-M-D) 2019-06-25 15:21:34' = 1561501294 epoch-seconds
date: timezone: system default
date: final: 1561501294.0 (epoch-seconds)
date: final: (Y-M-D) 2019-06-25 22:21:34 (UTC)
date: final: (Y-M-D) 2019-06-25 15:21:34 (UTC-07)
2019-06-25 15:21:34

#date -d "$datNow + 1 minute" "+%Y-%m-%d %H:%M:%S" --debug
date: parsed date part: (Y-M-D) 2019-06-25
date: parsed time part: 15:21:34 UTC+01
date: parsed relative part: +1 minutes
date: input timezone: parsed date/time string (+01)
date: using specified time as starting value: '15:21:34'
date: starting date/time: '(Y-M-D) 2019-06-25 15:21:34 TZ=+01'
date: '(Y-M-D) 2019-06-25 15:21:34 TZ=+01' = 1561472494 epoch-seconds
date: after time adjustment (+0 hours, +1 minutes, +0 seconds, +0 ns),
date: new time = 1561472554 epoch-seconds
date: timezone: system default
date: final: 1561472554.0 (epoch-seconds)
date: final: (Y-M-D) 2019-06-25 14:22:34 (UTC)
date: final: (Y-M-D) 2019-06-25 07:22:34 (UTC-07)

bug#35078: Possible bug in the date command, to do with %p

[Nicholas Joll]

Dear all

    The following relevant thing has been brought to my attention (by a
Conky developer):

 $  man strftime | grep Convert

    ^  Convert alphabetic characters in result string to
uppercase.

i.e., strftime, which is, I believe, a C function included in the C
'time' library, has an option (which one can use in Conky, actually) to
convert output to all uppercase - thus achieving what I desired. 'Date'
could implement something similar.

Yours

Nicholas

On 03/04/2019 04:08, Eric Blake wrote:
> On 4/2/19 3:22 PM, Nicholas Joll wrote:
>
>> I have two suggestions. (1) Amend the manual such that it says something
>> like the following.
>>
>>     %P like %p, but lower case (or uppercase if uppercase is all
>> that the locale provides)
>>
>> (2) Add (and document) a new option that works thusly:
>>
>>     %PP locale's implementation of AM/PM (or blank if the locale has
>> no such implementation), forced into uppercase
> We can't spell it %PP (that would be parsed as "%P" "P"), but we could
> take a leaf from %:z (and even %:::z) if we wanted to use : as a flag to
> force particular capitalizations.  Of course, even toupper()/tolower()
> are locale-dependent, so it's still hard to say what could really be
> forced if we added particular variants for overriding a locale's
> preferred case.
>

bug#33221: date command + 1 month

[Nicolás Flores]

Thanks for the tip!

Saludos,
Nicolás Flores
@fosnss


El mié., 31 de oct. de 2018 a la(s) 20:27, Assaf Gordon (
assafgor...@gmail.com) escribió:

> tags 33221 notabug
> close 33221
> stop
>
> Hello,
>
> On 2018-10-31 5:08 p.m., Nicolás Flores wrote:
> > Date Bug detected: Wed Oct 31 17:02:41 CST 2018
> > when executing
> > # *date +%b*
> > Result:
> > *Oct *
> > This is Ok, but...
> >
> > # *date +%b -d '+1 month'*
> > Result: *Dec*
> > Jump in the month of *November*
> >
>
> Indeed - that is the case, but it is not a bug.
> It is a limitation of date's internal working .
>
> date has a new --debug option that helps in troubleshooting
> such cases:
>
> ==
>$ date --debug -d '+1 month'
>date: parsed relative part: +1 month(s)
>date: input timezone: system default
>date: using current time as starting value: '20:17:28'
>date: using current date as starting value: '(Y-M-D) 2018-10-31'
>date: starting date/time: '(Y-M-D) 2018-10-31 20:17:28'
> **date: warning: when adding relative months/years, it is recommended to
>specify the 15th of the months**
>date: after date adjustment (+0 years, +1 months, +0 days),
>date: new date/time = '(Y-M-D) 2018-12-01 19:17:28'
>date: warning: daylight saving time changed after date adjustment
> **date: warning: month/year adjustment resulted in shifted dates:**
> **date:  adjusted Y M D: 2018 11 31**
>date:normalized Y M D: 2018 12 01
>date: '(Y-M-D) 2018-12-01 19:17:28' = 1543717048 epoch-seconds
>date: timezone: system default
>date: final: 1543717048.174426822 (epoch-seconds)
>date: final: (Y-M-D) 2018-12-02 02:17:28 (UTC)
>date: final: (Y-M-D) 2018-12-01 19:17:28 (UTC-07)
>Sat Dec  1 19:17:28 MST 2018
> ===
>
> I highlighted three lines in the debug output.
> When you added a month, internally date converted it to:
>year: 2018
>month: 10+1 = 11
>day: 31 (today's date).
>
> Then, date recognized that 31st of November is not a valid date,
> and normalized it to Dec 1st.
>
> The debug output includes a warning/recommendation:
> when adding/subtracting months, it is recommended to start from the
> 15th of the month.
> Example:
>
>$ date -d '2018-10-15 +1 month'
>Thu Nov 15 00:00:00 MST 2018
>$ date -d '2018-10-15 +1 month' +%b
>Nov
>
> To do it in a script (obtaining the current year/month):
>
>$ date -d "$(date +%Y-%m-15) +1 month" +%b
>Nov
>
> To see more similar examples (e.g. with leap years, and February), read
> the following thread:
> https://lists.gnu.org/archive/html/bug-coreutils/2018-02/msg5.html
>
>
> As such, I'm closing this bug.
> Discussion can continue by replying to this thread.
>
> -assaf
>

bug#33221: date command + 1 month

[Assaf Gordon]

tags 33221 notabug
close 33221
stop

Hello,

On 2018-10-31 5:08 p.m., Nicolás Flores wrote:

Date Bug detected: Wed Oct 31 17:02:41 CST 2018
when executing
# *date +%b*
Result:
*Oct *
This is Ok, but...

# *date +%b -d '+1 month'*
Result: *Dec*
Jump in the month of *November*



Indeed - that is the case, but it is not a bug.
It is a limitation of date's internal working .

date has a new --debug option that helps in troubleshooting
such cases:

==
  $ date --debug -d '+1 month'
  date: parsed relative part: +1 month(s)
  date: input timezone: system default
  date: using current time as starting value: '20:17:28'
  date: using current date as starting value: '(Y-M-D) 2018-10-31'
  date: starting date/time: '(Y-M-D) 2018-10-31 20:17:28'
**date: warning: when adding relative months/years, it is recommended to 
  specify the 15th of the months**

  date: after date adjustment (+0 years, +1 months, +0 days),
  date: new date/time = '(Y-M-D) 2018-12-01 19:17:28'
  date: warning: daylight saving time changed after date adjustment
**date: warning: month/year adjustment resulted in shifted dates:**
**date:  adjusted Y M D: 2018 11 31**
  date:normalized Y M D: 2018 12 01
  date: '(Y-M-D) 2018-12-01 19:17:28' = 1543717048 epoch-seconds
  date: timezone: system default
  date: final: 1543717048.174426822 (epoch-seconds)
  date: final: (Y-M-D) 2018-12-02 02:17:28 (UTC)
  date: final: (Y-M-D) 2018-12-01 19:17:28 (UTC-07)
  Sat Dec  1 19:17:28 MST 2018
===

I highlighted three lines in the debug output.
When you added a month, internally date converted it to:
  year: 2018
  month: 10+1 = 11
  day: 31 (today's date).

Then, date recognized that 31st of November is not a valid date,
and normalized it to Dec 1st.

The debug output includes a warning/recommendation:
when adding/subtracting months, it is recommended to start from the
15th of the month.
Example:

  $ date -d '2018-10-15 +1 month'
  Thu Nov 15 00:00:00 MST 2018
  $ date -d '2018-10-15 +1 month' +%b
  Nov

To do it in a script (obtaining the current year/month):

  $ date -d "$(date +%Y-%m-15) +1 month" +%b
  Nov

To see more similar examples (e.g. with leap years, and February), read
the following thread:
   https://lists.gnu.org/archive/html/bug-coreutils/2018-02/msg5.html


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

-assaf

bug#33221: date command + 1 month

[Nicolás Flores]

Date Bug detected: Wed Oct 31 17:02:41 CST 2018
when executing
# *date +%b*
Result:
*Oct *
This is Ok, but...

# *date +%b -d '+1 month'*
Result: *Dec*
Jump in the month of *November*


@fosnss

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#30795: Issue with date command and EDT

[Paul Eggert]

On 03/15/2018 12:15 AM, Assaf Gordon wrote:

Technically it's an easy fix (patch attached),
but it changes a long-standing behavior.


Yes, that's a problem. Perhaps we should take the last unit requested in 
the output format, divide that by two, and add that to the time instead. 
If the output format is %Y-%m-%d the output unit is one day, so we'd add 
12 hours. With the default output format we'd add only 0.5 s, which 
would be a no-op.


This isn't as fancy as what Pádraig is proposing, but it should be easy 
to implement.

bug#30795: Issue with date command and EDT

[Pádraig Brady]

On 15/03/18 00:15, Assaf Gordon wrote:
> Hello,
> 
> On Wed, Mar 14, 2018 at 05:22:04PM -0700, Paul Eggert wrote:
>> On 03/13/2018 06:42 PM, Assaf Gordon wrote:
>>> Therefore it is always recommended to use noon (12pm)
>>> as explicit time when adjusting days
>>
>> Maybe "date" should default to 12:00 instead of to 00:00 when the time is
>> not specified? That would avoid this sort of problem, typically.
> 
> Technically it's an easy fix (patch attached),
> but it changes a long-standing behavior.
> 
> I wonder if it will break some existing scripts that might rely
> on being 'midnight'? (even implicitly, because the user isn't aware of
> this nuance).
> 
> For example, currently '2018-03-15 + 14 hours' is 2pm on March 15th.
> With this change, it'll result in 2am on March 16th.
> 
> What do you think?

Yes picking 12:00 always is too simplistic I think.
The base should be dependent on the relative unit.
I proposed a solution previously at: http://bugs.gnu.org/18159#8

See also https://bugs.gnu.org/11101

cheers,
Pádraig

bug#30795: Issue with date command and EDT

[Assaf Gordon]

Hello,

On Wed, Mar 14, 2018 at 05:22:04PM -0700, Paul Eggert wrote:
> On 03/13/2018 06:42 PM, Assaf Gordon wrote:
> >Therefore it is always recommended to use noon (12pm)
> >as explicit time when adjusting days
> 
> Maybe "date" should default to 12:00 instead of to 00:00 when the time is
> not specified? That would avoid this sort of problem, typically.

Technically it's an easy fix (patch attached),
but it changes a long-standing behavior.

I wonder if it will break some existing scripts that might rely
on being 'midnight'? (even implicitly, because the user isn't aware of
this nuance).

For example, currently '2018-03-15 + 14 hours' is 2pm on March 15th.
With this change, it'll result in 2am on March 16th.

What do you think?

-assaf
>From 364bbe1b8adbb2fd3a67569de412273711162aab Mon Sep 17 00:00:00 2001
From: Assaf Gordon 
Date: Thu, 15 Mar 2018 00:59:28 -0600
Subject: [PATCH] parse-datetime: default to noon for dates without time

Prefer noon (instead of midnight) to reduce unexpected date shifts
with date arithmetics. Discussed in https://bugs.gnu.org/30795#11

* lib/parse-datetime.y (parse_datetime2): Set tm_hour to 12 (noon)
instead of 0 (midnight) if time wasn't given.
---
 ChangeLog| 8 
 lib/parse-datetime.y | 5 +++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a9cd4ae..e71935d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2018-03-15  Assaf Gordon 
+
+	parse-datetime: default to noon for dates without time
+	Prefer noon (instead of midnight) to reduce unexpected date shifts
+	with date arithmetics. Discussed in https://bugs.gnu.org/30795#11
+	* lib/parse-datetime.y (parse_datetime2): Set tm_hour to 12 (noon)
+	instead of 0 (midnight) if time wasn't given.
+
 2018-03-08  Paul Eggert  
 
 	fflush: be more paranoid about libio.h change
diff --git a/lib/parse-datetime.y b/lib/parse-datetime.y
index f14bb31..7b183d9 100644
--- a/lib/parse-datetime.y
+++ b/lib/parse-datetime.y
@@ -2019,10 +2019,11 @@ parse_datetime2 (struct timespec *result, char const *p,
 }
   else
 {
-  tm.tm_hour = tm.tm_min = tm.tm_sec = 0;
+  tm.tm_hour = 12;
+  tm.tm_min = tm.tm_sec = 0;
   pc.seconds.tv_nsec = 0;
   if (pc.parse_datetime_debug)
-dbg_printf ("warning: using midnight as starting time: 00:00:00\n");
+dbg_printf ("warning: using noon as starting time: 12:00:00\n");
 }
 
   /* Let mktime deduce tm_isdst if we have an absolute timestamp.  */
-- 
2.7.4

bug#30795: Issue with date command and EDT

[Paul Eggert]

On 03/13/2018 06:42 PM, Assaf Gordon wrote:

Therefore it is always recommended to use noon (12pm)
as explicit time when adjusting days


Maybe "date" should default to 12:00 instead of to 00:00 when the time 
is not specified? That would avoid this sort of problem, typically.

bug#30795: Issue with date command and EDT

[Assaf Gordon]

Hello,

On 2018-03-13 09:20 AM, Jared Chagnon wrote:

I setup a test script:

#/bin/bash

echo "`date`"
echo "`date +%z`"

currentdate=`date +%Y%m%d_%H%M%S`
echo "current date: $currentdate"

olddate=`date "+%Y%m%d_%H%M%S" --date='4 days ago'`
echo "old date 4 days ago: $olddate”


An unrelated suggestion:
There's no need to use backticks to execute date and return the value
and then echo it. Simply running 'date' will print the date to STDOUT.
e.g.

  date
  date +%z
  printf "current date: "
  date +%Y%m%d_%H%M%S

or even:

  date +"Current Date: %Y%m%d_%H%M%S"


— Output —

./datetest.sh
Tue Mar 13 09:08:34 EDT 2018
-0400
current date: 20180313_090834
old date 4 days ago: 20180309_080834

— Notes ——

My local time zone is America\New_York.  Please note the date modification is 
not using EDT and resulting in EST.


First,
lets verify our baseline assumptions about New York time zones
are the same:

EST = Eastern Standard Time, used in autumn/winter = UTC-05:00.
EDT = Eastern Daylight Time, used in spring/summer = UTC-04:00.

In 2018, daylight saving time (DST) started on March 11th, 2:am.
"started" here means switching from EST to EDT.

That is:
  2018-03-09 is EST (still winter, DST not used).
  2018-03-13 is EDT (summer time, DST used).

This can be verified with:

  $ TZ="America/New_York" date +%F-%Z -d '2018-03-09'
  2018-03-09-EST
  $ TZ="America/New_York" date +%F-%Z -d '2018-03-13'
  2018-03-13-EDT


Second,
in your example, the current date is 2018-03-13 (and implied: EDT),
and subtracting 4 days gives 2018-03-09.
Due to your time zone, 'date' knows that your timezone does use DST.
This date adjustment also crossed the DST change date (march 11th),
so date correctly adjusted the clock one hour backwards (from
09:08:34 to 08:08:34.


Third,
in newer version we've added a "--debug" option that helps
diagnosing such issues:

  $ TZ="America/New_York" \
 date --debug +%Y%m%d_%H%M%S_%Z --date="4 days ago"
  date: parsed relative part: -4 day(s)
  date: input timezone: TZ="America/New_York" environment value
  date: using current time as starting value: '21:13:23'
  date: using current date as starting value: '(Y-M-D) 2018-03-13'
  date: starting date/time: '(Y-M-D) 2018-03-13 21:13:23'
  date: warning: when adding relative days, it is recommended to \
specify noon
  date: after date adjustment (+0 years, +0 months, -4 days),
  date: new date/time = '(Y-M-D) 2018-03-09 20:13:23'
->date: warning: daylight saving time changed after date adjustment <-
  date: '(Y-M-D) 2018-03-09 20:13:23' = 1520644403 epoch-seconds
  date: timezone: TZ="America/New_York" environment value
  date: final: 1520644403.136862048 (epoch-seconds)
  date: final: (Y-M-D) 2018-03-10 01:13:23 (UTC)
  date: final: (Y-M-D) 2018-03-09 20:13:23 (UTC-05)
  20180309_201323_EST



Fourth,
There is a subtle issue of how 'date' knows when to do DST adjustments
(and when not to).

When using 'date' without specifying the current date/time, it
gets the date,time and time zone from your operating system.

In your case it was "America/New_York". 'date' then checked the timezone
database and so it knows that NY does use daylight saving time,
and it knows that currently it is EDT, will subtract an hour when 
switching to EST.


When giving 'date' an explicit date without time zone, it doesn't
know if DST should be used or not - and assumes it should not be used.
Therefore it will not subtract an hour.

Observe the following:

  $ date +%F
  2018-03-13

  # Without timezone - hour stays the same:
  $ date -d '2018-03-13 09:00:00 4 days ago'
  Fri Mar  9 09:00:00 EST 2018

  # With timezone that indicates DST - hour is adjusted:
  $ date -d '2018-03-13 09:00:00 EDT 4 days ago'
  Fri Mar  9 08:00:00 EST 2018

These issues can be troubleshooted using the "--debug" option.



Fifth,
There is also one additional nuance:
If you don't specify the hour, 'date' assumes midnight.
If DST is active, it will subtract an hour resulting in 11pm
in the previous day:

  $ date -d '2018-03-13 4 days ago'
  Fri Mar  9 00:00:00 EST 2018

  $ date -d '2018-03-13 EDT 4 days ago'
  Thu Mar  8 23:00:00 EST 2018

This will be very confusing if one prints only the date, eg:

  $ date -d '2018-03-13 4 days ago' +%F
  2018-03-09

  $ date -d '2018-03-13 EDT 4 days ago' +%F
  2018-03-08

Therefore it is always recommended to use noon (12pm)
as explicit time when adjusting days (and when using --debug
there will be a warning to that effect).








If this explanation solves the issue - great.
If not, please provide further details and examples of the commands and
output you expect.

regards,
 - assaf

bug#30795: Issue with date command and EDT

[Jared Chagnon]

Forgot to include this:

OS Release:
Red Hat Enterprise Linux Server release 6.9 (Santiago)

Packages installed:
tzdata-2018c-1.el6.noarch
coreutils-8.4-46.0.1.el6.x86_64
coreutils-libs-8.4-46.0.1.el6.x86_64

Jared Chagnon
Systems Engineering Manager
P:  781.292.6033
M:  508.566.0081
jchag...@enservio.com
www.enservio.com

[cid:A7AEE8A5-9D9D-44B8-B77C-BE36F5D6A2C5@enservio.lan]

On Mar 13, 2018, at 9:10 AM, Jared Chagnon 
> wrote:

Please see the issue below:

I setup a test script:

#/bin/bash

echo "`date`"
echo "`date +%z`"

currentdate=`date +%Y%m%d_%H%M%S`
echo "current date: $currentdate"

olddate=`date "+%Y%m%d_%H%M%S" --date='4 days ago'`
echo "old date 4 days ago: $olddate”

— Output —

./datetest.sh
Tue Mar 13 09:08:34 EDT 2018
-0400
current date: 20180313_090834
old date 4 days ago: 20180309_080834

— Notes ——

My local time zone is America\New_York.  Please note the date modification is 
not using EDT and resulting in EST.

Jared Chagnon
Systems Engineering Manager
P:  781.292.6033
M:  508.566.0081
jchag...@enservio.com
www.enservio.com

[cid:A7AEE8A5-9D9D-44B8-B77C-BE36F5D6A2C5@enservio.lan]

bug#19856: Bad month translation printed with date command in Greek locale

[Paul Eggert]

On 03/06/2018 02:42 PM, Rafal Luzynski wrote:

So the only thing that needs to be done for coreutils is to bump the
version of Gnulib module used and make sure that the most recent glibc
is used.


Thanks for letting us know. I installed the attached into coreutils 
master and marking this bug as done, since this is all that should be 
needed as far as coreutils itself is concerned.


>From db94330dd65b246f4fb96e017f1425fe0c1246a8 Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Tue, 6 Mar 2018 15:15:24 -0800
Subject: [PATCH] build: update gnulib submodule to latest

---
 gnulib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnulib b/gnulib
index d9afeacd0..59e59d99b 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit d9afeacd0e2396deaabab291ab94e09ab9834fdb
+Subproject commit 59e59d99bc1ca635d178778b9b4ee544330775c4
-- 
2.14.3

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

 

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

 

Best regards,

 

Maarten Mastbroek

 

bug#19856: Bad month translation printed with date command in Greek locale

[Andries E. Brouwer]

On Fri, Feb 13, 2015 at 03:56:25PM -0700, Eric Blake wrote:

 It also looks like the POSIX wording is very specific on which
 of the two forms is genitive vs nominative

In general such words (like genitive) are not appropriate.
Different languages have different systems of flection,
and the situation is far too complicated for POSIX to describe.

In many languages the day number is an ordinal number, not a cardinal number.
Even for English I don't know whether there is a convenient way
to generate April 1st, April 2nd. Or for French 1er avril, 2 avril.

Andries

bug#19856: Bad month translation printed with date command in Greek locale

[Nick John]

Hello we are Nick Barkas and Ioannis Barkas from Greece. There is an
annoying error in the date command for quite some time when using
Greek locale.
If date is instructed to print month and day of month, the translation
is wrong and looks funny...
 You have to be able to write Greek in order to understand it and
since the bug exists we assume no one from coreutils developers knows
Greek.
 As a result we will explain every month in detail as it will be Greek
to you. Remove LC_TIME=el_GR.UTF-8 from the commands to get the date
in English.

This is what you get with B Y (month year), which is correct:
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-01-01
Ιανουάριος 2015
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-02-01
Φεβρουάριος 2015
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-03-01
Μάρτιος 2015
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-04-01
Απρίλιος 2015
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-05-01
Μάιος 2015
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-06-01
Ιούνιος 2015
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-07-01
Ιούλιος 2015
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-08-01
Αύγουστος 2015
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-09-01
Σεπτέμβριος 2015
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-10-01
Οκτώβριος 2015
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-11-01
Νοέμβριος 2015
$ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-12-01
Δεκέμβριος 2015

This is what you get with d B Y (month year), which is wrong:
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-01-01
01 Ιανουάριος 2015
damn@rsee:~$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-02-01
01 Φεβρουάριος 2015
damn@rsee:~$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-03-01
01 Μάρτιος 2015
damn@rsee:~$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-04-01
01 Απρίλιος 2015
damn@rsee:~$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-05-01
01 Μάιος 2015
damn@rsee:~$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-06-01
01 Ιούνιος 2015
damn@rsee:~$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-07-01
01 Ιούλιος 2015
damn@rsee:~$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-08-01
01 Αύγουστος 2015
damn@rsee:~$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-09-01
01 Σεπτέμβριος 2015
damn@rsee:~$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-10-01
01 Οκτώβριος 2015
damn@rsee:~$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-11-01
01 Νοέμβριος 2015
damn@rsee:~$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-12-01
01 Δεκέμβριος 2015

Here is what the date command should print with d B Y (month year),
in el_GR.UTF-8 locale:
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-01-01
01 Ιανουαρίου 2015
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-02-01
01 Φεβρουαρίου 2015
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-03-01
01 Μαρτίου 2015
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-04-01
01 Απριλίου 2015
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-05-01
01 Μαίου 2015
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-06-01
01 Ιουνίου 2015
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-07-01
01 Ιουλίου 2015
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-08-01
01 Αυγούστου 2015
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-09-01
01 Σεπτεμβρίου 2015
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-10-01
01 Οκτωβρίου 2015
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-11-01
01 Νοεμβρίου 2015
$ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-12-01
01 Δεκεμβρίου 2015

In Greek language things are different and complex compared to
English. We have accents (τόνους) for most words and words are not
fixed but can dynamically change depending on context.
When the month is accompanied by a day of month the accent (Greek
tonos/τόνος) changes and ...ος becomes ...ου. To fix this, use the
correct translations for months, if and only if %B
 and %d are used together. If the month is called with no day (%d)
using %B or if the month is called with %d %b or %b leave the
translations as they are.
Since there are many computer-science oriented Greek universities and
so many Greeks around the world, we are amazed that no one fixed it so
far.
We must also inform you that this silly bug of yours has been seen in webpages.

bug#19856: Bad month translation printed with date command in Greek locale

[Paul Eggert]

If I understand correctly, it doesn't appear that this is a bug that coreutils 
can fix, as POSIX implies (and many programs expect) that formats like %d and %B 
and %Y act independently of context.


If it's any consolation, the default output of 'date' in the C locale:

Thu Jun 28 15:10:00 PDT 2014

is bogus for me too, as Americans by and large neither write 'Jun' as an 
abbreviation for 'June' nor use 24-hour timestamps.

bug#19856: Bad month translation printed with date command in Greek locale

[Eric Blake]

[adding the Austin Group, as this is a POSIX question]

On 02/13/2015 06:46 AM, Nick  John wrote:
 Hello we are Nick Barkas and Ioannis Barkas from Greece. There is an
 annoying error in the date command for quite some time when using
 Greek locale.

Thanks for the report.

 If date is instructed to print month and day of month, the translation
 is wrong and looks funny...
  You have to be able to write Greek in order to understand it and
 since the bug exists we assume no one from coreutils developers knows
 Greek.
  As a result we will explain every month in detail as it will be Greek
 to you.

I don't know if you intended that to be funny, but it makes a rather
nice play on a typical English idiom :)

 Remove LC_TIME=el_GR.UTF-8 from the commands to get the date
 in English.
 
 This is what you get with B Y (month year), which is correct:
 $ LC_TIME=el_GR.UTF-8 date +%B %Y -d 2015-01-01
 Ιανουάριος 2015

 
 This is what you get with d B Y (month year), which is wrong:
 $ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-01-01
 01 Ιανουάριος 2015

 
 Here is what the date command should print with d B Y (month year),
 in el_GR.UTF-8 locale:
 $ LC_TIME=el_GR.UTF-8 date +%d %B %Y -d 2015-01-01
 01 Ιανουαρίου 2015

 
 In Greek language things are different and complex compared to
 English. We have accents (τόνους) for most words and words are not
 fixed but can dynamically change depending on context.
 When the month is accompanied by a day of month the accent (Greek
 tonos/τόνος) changes and ...ος becomes ...ου. To fix this, use the
 correct translations for months, if and only if %B
  and %d are used together. If the month is called with no day (%d)
 using %B or if the month is called with %d %b or %b leave the
 translations as they are.

What should REALLY happen is that libc's strftime(3) (which is what
date(1) uses under the hood - the % modifiers are the same) should
support something like %OB to trigger a locale's alternative
representation, as the %O modifier is already used for other locales
that have different displays.

But right now, POSIX says %OB is undefined behavior (look for the
section on Modified Conversion Specifiers):
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html

and on glibc, it does nothing:

$ LC_TIME=el_GR.UTF-8 date +%d %OB %Y -d 2015-12-01
01 %OB 2015

I guess what it boils down to is that when defining a locale, the
existing 'era', 'era_d_format', 'era_t_format', and 'era_d_t_format'
affect existing %E uses, and 'alt_digits' affects existing %O uses
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_03_05

and the ideal solution would be adding a new locale file entry for
'alt_months' that would then let %OB provide the locale's alternate
month names.  Then you could write your string as %d %OB %Y to get the
grammatically correct output.

 Since there are many computer-science oriented Greek universities and
 so many Greeks around the world, we are amazed that no one fixed it so
 far.
 We must also inform you that this silly bug of yours has been seen in 
 webpages.

Coreutils will automatically pick up any fixes in glibc, you'll need to
get it fixed there first.  It would be nice to get POSIX to standardize
%OB, but that would be easier if you could first get glibc to implement
the solution to show that it makes sense.

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



signature.asc
Description: OpenPGP digital signature

bug#19856: Bad month translation printed with date command in Greek locale

[Eric Blake]

On 02/13/2015 01:17 PM, Jilles Tjoelker wrote:

 The functionality already works in FreeBSD, for example:
 
 $ LC_TIME=el_GR.UTF-8 date +%d %B %Y
 13 Φεβρουαρίου 2015
 $ LC_TIME=el_GR.UTF-8 date +%OB %Y
 Φεβρουάριος 2015
 
 It was implemented for Greek in 2001:
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=32120

Thanks for reminding me of that.  Wow, 5 years where glibc has not
picked it up is a bit long; I've added information to what looks like
the most relevant glibc bug
https://sourceware.org/bugzilla/show_bug.cgi?id=12651 to see if we can
get more eyes on it and hopefully implemented for more than just BSD
systems.  It also looks like the POSIX wording is very specific on which
of the two forms is genitive vs nominative, and that glibc's current
locale is using the wrong form for %B.

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



signature.asc
Description: OpenPGP digital signature

bug#19856: Bad month translation printed with date command in Greek locale

[Jilles Tjoelker]

On Fri, Feb 13, 2015 at 02:20:58PM -0500, Garrett Wollman wrote:
 On Fri, 13 Feb 2015 10:56:34 -0700, Eric Blake ebl...@redhat.com said:

  Coreutils will automatically pick up any fixes in glibc, you'll need to
  get it fixed there first.  It would be nice to get POSIX to standardize
  %OB, but that would be easier if you could first get glibc to implement
  the solution to show that it makes sense.

 FreeBSD has long implemented %OB, for Russian IIRC.  It's documented
 thus:

Additionally %OB implemented to represent alternative months names
(used standalone, without day mentioned).

This feature was discussed here before, and an interpretation was issued
for issue 8: http://austingroupbugs.net/view.php?id=258

The functionality already works in FreeBSD, for example:

$ LC_TIME=el_GR.UTF-8 date +%d %B %Y
13 Φεβρουαρίου 2015
$ LC_TIME=el_GR.UTF-8 date +%OB %Y
Φεβρουάριος 2015

It was implemented for Greek in 2001:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=32120

-- 
Jilles Tjoelker

bug#19856: Bad month translation printed with date command in Greek locale

[Garrett Wollman]

On Fri, 13 Feb 2015 10:56:34 -0700, Eric Blake ebl...@redhat.com said:

 Coreutils will automatically pick up any fixes in glibc, you'll need to
 get it fixed there first.  It would be nice to get POSIX to standardize
 %OB, but that would be easier if you could first get glibc to implement
 the solution to show that it makes sense.

FreeBSD has long implemented %OB, for Russian IIRC.  It's documented
thus:

   Additionally %OB implemented to represent alternative months names
   (used standalone, without day mentioned).

-GAWollman

bug#16606: date command throws error when DST is turned on

[Lakshmi Ramamurthi -X (lramamur - HCL TECHNOLOGIES LIMITED at Cisco)]

Hi,

The date command throws error when the DST is turned on.

# date +%s -d 2013/11/20
1384912800
# date +%s -d 2013/10/20
date: invalid date `2013/10/20'

1 sec after Oct 19 23:59:59 2013 becomes Oct 20 01:00:00 2013
As there is no 0th hour on Oct 20, it shows invalid date.

Are there any options to fix this problems ?
Has there been a patch posted for this.


#date
Sun Mar 10 07:02:07 BRT 2013

# zdump -v /etc/localtime | grep 2013
/etc/localtime Sun Feb 17 01:59:59 2013 UTC = Sat Feb 16 23:59:59 2013 BRST 
isdst=1 gmtoff=-7200
/etc/localtime Sun Feb 17 02:00:00 2013 UTC = Sat Feb 16 23:00:00 2013 BRT 
isdst=0 gmtoff=-10800
/etc/localtime Sun Oct 20 02:59:59 2013 UTC = Sat Oct 19 23:59:59 2013 BRT 
isdst=0 gmtoff=-10800
/etc/localtime Sun Oct 20 03:00:00 2013 UTC = Sun Oct 20 01:00:00 2013 BRST 
isdst=1 gmtoff=-7200

Thanks,
Lakshmi

bug#16606: date command throws error when DST is turned on

[Bob Proulx]

tag 16606 +notabug
close 16606
thanks

Lakshmi Ramamurthi -X (lramamur - HCL TECHNOLOGIES LIMITED at Cisco) wrote:
 The date command throws error when the DST is turned on.
 
 # date +%s -d 2013/11/20
 1384912800
 # date +%s -d 2013/10/20
 date: invalid date `2013/10/20'

 1 sec after Oct 19 23:59:59 2013 becomes Oct 20 01:00:00 2013
 As there is no 0th hour on Oct 20, it shows invalid date.

You are completely correct that there is no midnight in your timezone
and therefore the date you are requesting *in your timezone* does not
exist and therefore it is an invalid date.  The date command is
working correctly in reporting it as an invalid date.  I will
emphasize that this is timezone specific behavior.

 Are there any options to fix this problems ?
 Has there been a patch posted for this.

The option to fix this is the -u option to select UTC.  No patches are
needed.

The best choice is to work with dates in the UTC timezone which avoids
all DST issues since UTC never changes and never skips seconds.  The
second best choice is to work with times around noon which avoids DST
time changes that usually happen at night.  These hints are discussed
in the FAQ entry in more detail.

You didn't say what specific timezone you were concerned with so I
will pick one at random for an example.

  $ env TZ=America/Sao_Paulo date -R -d 2013/10/20
  date: invalid date ‘2013/10/20’

That date at midnight does not exist in that timezone.

  $ env TZ=America/Sao_Paulo date -R -d 2013/10/20 12:00
  Sun, 20 Oct 2013 12:00:00 -0200

Using 12:00 noon avoids the skipped interval.

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

Using UTC avoids the problem because UTC doesn't skip intervals for
DST.  I also didn't show setting a default timezone (TZ) because that
is also not matter when using UTC.  It is just simpler all around.

Please see the FAQ entry where this is explained in detail.

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

Bob

bug#16606: date command throws error when DST is turned on

[Lakshmi Ramamurthi -X (lramamur - HCL TECHNOLOGIES LIMITED at Cisco)]

Thanks a lot for your quick reply.

-Lakshmi

-Original Message-
From: Bob Proulx [mailto:b...@proulx.com] 
Sent: Friday, January 31, 2014 12:47 PM
To: Lakshmi Ramamurthi -X (lramamur - HCL TECHNOLOGIES LIMITED at Cisco)
Cc: 16...@debbugs.gnu.org
Subject: Re: bug#16606: date command throws error when DST is turned on

tag 16606 +notabug
close 16606
thanks

Lakshmi Ramamurthi -X (lramamur - HCL TECHNOLOGIES LIMITED at Cisco) wrote:
 The date command throws error when the DST is turned on.
 
 # date +%s -d 2013/11/20
 1384912800
 # date +%s -d 2013/10/20
 date: invalid date `2013/10/20'

 1 sec after Oct 19 23:59:59 2013 becomes Oct 20 01:00:00 2013 As there 
 is no 0th hour on Oct 20, it shows invalid date.

You are completely correct that there is no midnight in your timezone and 
therefore the date you are requesting *in your timezone* does not exist and 
therefore it is an invalid date.  The date command is working correctly in 
reporting it as an invalid date.  I will emphasize that this is timezone 
specific behavior.

 Are there any options to fix this problems ?
 Has there been a patch posted for this.

The option to fix this is the -u option to select UTC.  No patches are needed.

The best choice is to work with dates in the UTC timezone which avoids all DST 
issues since UTC never changes and never skips seconds.  The second best choice 
is to work with times around noon which avoids DST time changes that usually 
happen at night.  These hints are discussed in the FAQ entry in more detail.

You didn't say what specific timezone you were concerned with so I will pick 
one at random for an example.

  $ env TZ=America/Sao_Paulo date -R -d 2013/10/20
  date: invalid date ‘2013/10/20’

That date at midnight does not exist in that timezone.

  $ env TZ=America/Sao_Paulo date -R -d 2013/10/20 12:00
  Sun, 20 Oct 2013 12:00:00 -0200

Using 12:00 noon avoids the skipped interval.

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

Using UTC avoids the problem because UTC doesn't skip intervals for DST.  I 
also didn't show setting a default timezone (TZ) because that is also not 
matter when using UTC.  It is just simpler all around.

Please see the FAQ entry where this is explained in detail.

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

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#14146: [date command] Possible bug

[Ivan Lombardi Borgia]

Good morning,

for the 1th of April 2013 the command *date *has this interesting behaviour:
*
*
*$ date*
*Mon Apr  1 00:22:31 CEST 2013*
*$ date -d 'yesterday'*
*Sat Mar 30 23:22:38 CET 2013*
*
*
As you can read the date is 30 March instead of 31 the time 23:22 instead
of 00:22

I could verify that on:

   - my personal machine running:
   Linux dip03-ubu 3.2.0-40-generic-pae #64-Ubuntu
   date --version: date (GNU coreutils) 8.13
   - production servers running:
   Linux ecomappsrv01 2.6.38-8-generic-pae #42-Ubuntu
   date --version: date (GNU coreutils) 8.5

That doesn't happen for year 2012 and 2014.
It happens even using -u option.
It does not happen forcing date:
*date -d '2013-04-01 00:22:00 1 day ago' *
*Sun Mar 31 00:22:00 CET 2013*
*
*
If you need more information just ask and I will try to respond as soon as
possible.

Thank you, best regards.


Ivan Lombardi Borgia

bug#14146: [date command] Possible bug

[Eric Blake]

tag 14146 notabug
thanks

On 04/05/2013 03:13 AM, Ivan Lombardi Borgia wrote:
 Good morning,
 
 for the 1th of April 2013 the command *date *has this interesting behaviour:
 *
 *
 *$ date*
 *Mon Apr  1 00:22:31 CEST 2013*
 *$ date -d 'yesterday'*
 *Sat Mar 30 23:22:38 CET 2013*

Did you notice the change in the time zone name from CEST to CET, based
on daylight savings?

 That doesn't happen for year 2012 and 2014.

Yeah, because daylight savings in your timezone falls on a different
date in those years.

 If you need more information just ask and I will try to respond as soon as
 possible.

You are hitting a typical usage problem.  This is not a bug in date, but
in your usage of it; you are failing to account that yesterday
translates to 24 hours ago, but that 24 hours ago close to midnight
when crossing over a 23-hour day (thanks to daylight savings) can cross
2 calendar days.

For more information, including the tip to base relative date
computation on noon instead of close to midnight, see the FAQ:

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

As such, I'm closing this as not a bug, although you may feel free to
continue replying if you have further questions.

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



signature.asc
Description: OpenPGP digital signature

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#11125: date command calculations are not consistent

[Thomas R. Schaefer]

Thanks Eric  Bob.  Good stuff.  I'm still slightly foggy on why I get 
different answers subtracting 35 days from seemingly the same point in time..

[tschaefer@schaefer-test ~]$ date  -d 'last Thursday'
Thu Mar 29 00:00:00 CDT 2012
[tschaefer@schaefer-test ~]$ date  -d 'Thu Mar 29 00:00:00 CDT 2012 - 35 days'
Wed Feb 22 23:00:00 CST 2012
[tschaefer@schaefer-test ~]$ date -d 'last Thursday - 35 days'
Thu Feb 23 00:00:00 CST 2012

But, I'm probably just to dense to get it.

Thanks again for the help.  The suggestion of using noon today when 
subtracting days from a date is an excellent one.

Tom Schaefer

--- On Thu, 3/29/12, Bob Proulx b...@proulx.com wrote:

From: Bob Proulx b...@proulx.com
Subject: Re: bug#11125: date command calculations are not consistent
To: Thomas R. Schaefer schaef...@yahoo.com, 11...@debbugs.gnu.org
Date: Thursday, March 29, 2012, 10:35 PM

Eric Blake wrote:
 Thomas R. Schaefer wrote:
  In this case date does take DST into account in a relative date operation..
  
  [root@schaefer-test ~]# date -d last Thursday - 21 days
  Thu Mar  1 00:00:00 CST 2012
 
 But notice what date -d last Thursday is:
 
 $ TZ=CST date -d 'last Thursday CST'
 Thu Mar 22 00:00:00 CST 2012
 
 It's relative to the 'CST' timezone, which is an hour different from the
 CDT timezone.

Additionally it is working near the problematic midnight time when
crosing DST boundaries may cause problems.

  If the date command where being consistent in following the
  consensus that relative date operations add or subtract in
  multiples of 24 hours, without regards to daylight savings
  boundaries then both of the above date commands would return Wed
  Feb 29 23:00:00 CST 2012.
 
 Only if you start from the same point in time in both commands, which
 you didn't.

For an example always use a time in addition to a day.  Never default
to midnight.  Instead use 12:00 noon to avoid the DST problems.

  $ TZ=US/Mountain date -R -d 'last Thursday'
  Thu, 22 Mar 2012 00:00:00 -0600

That is problematic usage.  But specifying the time as 12:00 noon
solves the problem.

  $ TZ=US/Mountain date -R -d '12:00 last Thursday'
  Thu, 22 Mar 2012 12:00:00 -0600

Then doing calculations will be more reliable.

  $ TZ=US/Mountain date -R -d '12:00 last Thursday - 21 days'
  Thu, 01 Mar 2012 12:00:00 -0700

Note that I always use -R to obtain an unambiguous format.  Using the
default format isn't unambiguous as there are multiple timezones with
the same names.

Doing calculations on weeks and months have similar issues.  When
doing calculations on months I always work with the middle of the
month to avoid the difference in lenghts of months.

Generate a reference date in the middle of the month.

  $ date +%Y-%m-15
  2012-03-15

Use that date for month calculations.

  $ date --date=$(date +%Y-%m-15) -1 month +'Last month was %B.'
  Last month was February.

Please see the FAQ for more examples:

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

Unfortunately the human date parsing that was added to date is a
rather simplistic implementation.

Bob

bug#11125: date command calculations are not consistent

[Thomas R. Schaefer]

Discovered this when I script I have cronned to run at 12:01AM gave some 
unexpected results.

After much picking at it I finally figured out that the date command itself was 
the source of my problem.  It isn't handling date calculations that span the 
daylight savings time change consistently..

[schaefer@fedora14 ~]$ date --version
date (GNU coreutils) 8.5
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.
[schaefer@fedora14 ~]$ date -d last Thursday
Thu Mar 22 00:00:00 CDT 2012
[schaefer@fedora14 ~]$ date -d Thu Mar 22 00:00:00 CDT 2012
Thu Mar 22 00:00:00 CDT 2012
[schaefer@fedora14 ~]$ date -d last Thursday - 21 days
Thu Mar  1 00:00:00 CST 2012
[schaefer@fedora14 ~]$ date -d Thu Mar 22 00:00:00 CDT 2012 - 21 days
Wed Feb 29 23:00:00 CST 2012

In my real world case I was running a script at 12:01AM on Sundays that did 
this..

RSD=$(date +%F -d today - 35  days) # Report Start Date

RSD was getting set to a Saturday date but ordinarily, when a DST change hasn't 
occurred in the past 35 days, it would be set to a Sunday date.  I expect and 
want the Sunday date regardless; although I realize an argument could be made 
for the correctness of the Saturday date too.  However the date command is 
going to make a calculation like that it should be consistent with its own self 
which if you look closely at my examples above regarding last Thursday you will 
see it is not consistent with itself.

Thank you,
Tom Schaefer

bug#11125: date command calculations are not consistent

[Eric Blake]

forcemerge 11098 11125
thanks

On 03/29/2012 11:43 AM, Thomas R. Schaefer wrote:
 Discovered this when I script I have cronned to run at 12:01AM gave some 
 unexpected results.
 
 After much picking at it I finally figured out that the date command itself 
 was the source of my problem.  It isn't handling date calculations that span 
 the daylight savings time change consistently

Thanks for the report.  Join the club.  This has been reported twice
this week already, and the consensus is that date is behaving as
documented (relative date operations add or subtract in multiples of 24
hours, without regards to daylight savings boundaries), but that the
documented behavior could be improved if someone were to submit a patch.

https://lists.gnu.org/archive/html/bug-coreutils/2012-03/msg00102.html

As recommended in our FAQ,

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

it's almost always better to base relative time computations off of noon
rather than midnight (as both 11 am and 1 pm fall in the same day, even
when your multiple-of-24-hours crosses a 23-hour or 25-hour day).

In your example, change:

RSD=$(date +%F -d today - 35  days) # Report Start Date

to:

RSD=$(date +%F -d noon today - 35  days) # Report Start Date

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



signature.asc
Description: OpenPGP digital signature

bug#11125: date command calculations are not consistent

[Thomas R. Schaefer]

Thank you, I really appreciate your suggestion and will use it in my script.  
That will solve my problem.

I can appreciate the consensus that relative date operations add or subtract 
in multiples of 24 hours, without regards to daylight savings boundaries.  In 
fact I would be inclined to agree with it.

But if that is the consensus then I believe the date command should adhere to 
that consensus consistently which it does not.

In this case date is calculating with 24 hours days regardless of crossing a 
DST boundary..

[root@schaefer-test ~]# date -d Thu Mar 22 00:00:00 CDT 2012 - 21 days
Wed Feb 29 23:00:00 CST 2012

In this case date does take DST into account in a relative date operation..

[root@schaefer-test ~]# date -d last Thursday - 21 days
Thu Mar  1 00:00:00 CST 2012

If the date command where being consistent in following the consensus that 
relative date operations add or subtract in multiples of 24 hours, without 
regards to daylight savings boundaries then both of the above date commands 
would return Wed Feb 29 23:00:00 CST 2012.

Again thank you for your help,

Tom Schaefer










--- On Thu, 3/29/12, Eric Blake ebl...@redhat.com wrote:

From: Eric Blake ebl...@redhat.com
Subject: Re: bug#11125: date command calculations are not consistent
To: Thomas R. Schaefer schaef...@yahoo.com
Cc: 11...@debbugs.gnu.org
Date: Thursday, March 29, 2012, 1:01 PM

forcemerge 11098 11125
thanks

On 03/29/2012 11:43 AM, Thomas R. Schaefer wrote:
 Discovered this when I script I have cronned to run at 12:01AM gave some 
 unexpected results.
 
 After much picking at it I finally figured out that the date command itself 
 was the source of my problem.  It isn't handling date calculations that span 
 the daylight savings time change consistently

Thanks for the report.  Join the club.  This has been reported twice
this week already, and the consensus is that date is behaving as
documented (relative date operations add or subtract in multiples of 24
hours, without regards to daylight savings boundaries), but that the
documented behavior could be improved if someone were to submit a patch.

https://lists.gnu.org/archive/html/bug-coreutils/2012-03/msg00102.html

As recommended in our FAQ,

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

it's almost always better to base relative time computations off of noon
rather than midnight (as both 11 am and 1 pm fall in the same day, even
when your multiple-of-24-hours crosses a 23-hour or 25-hour day).

In your example, change:

RSD=$(date +%F -d today - 35  days) # Report Start Date

to:

RSD=$(date +%F -d noon today - 35  days) # Report Start Date

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

bug#11125: date command calculations are not consistent

[Eric Blake]

On 03/29/2012 12:34 PM, Thomas R. Schaefer wrote:

 In this case date is calculating with 24 hours days regardless of crossing a 
 DST boundary..
 
 [root@schaefer-test ~]# date -d Thu Mar 22 00:00:00 CDT 2012 - 21 days
 Wed Feb 29 23:00:00 CST 2012

This started from one fixed point in time, relative to the 'CDT' time
zone, and subtracted 21 * 24 hours.

 
 In this case date does take DST into account in a relative date operation..
 
 [root@schaefer-test ~]# date -d last Thursday - 21 days
 Thu Mar  1 00:00:00 CST 2012

But notice what date -d last Thursday is:

$ TZ=CST date -d 'last Thursday CST'
Thu Mar 22 00:00:00 CST 2012

It's relative to the 'CST' timezone, which is an hour different from the
CDT timezone.

 
 If the date command where being consistent in following the consensus that 
 relative date operations add or subtract in multiples of 24 hours, without 
 regards to daylight savings boundaries then both of the above date commands 
 would return Wed Feb 29 23:00:00 CST 2012.

Only if you start from the same point in time in both commands, which
you didn't.

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



signature.asc
Description: OpenPGP digital signature

bug#11125: date command calculations are not consistent

[Bob Proulx]

Eric Blake wrote:
 Thomas R. Schaefer wrote:
  In this case date does take DST into account in a relative date operation..
  
  [root@schaefer-test ~]# date -d last Thursday - 21 days
  Thu Mar  1 00:00:00 CST 2012
 
 But notice what date -d last Thursday is:
 
 $ TZ=CST date -d 'last Thursday CST'
 Thu Mar 22 00:00:00 CST 2012
 
 It's relative to the 'CST' timezone, which is an hour different from the
 CDT timezone.

Additionally it is working near the problematic midnight time when
crosing DST boundaries may cause problems.

  If the date command where being consistent in following the
  consensus that relative date operations add or subtract in
  multiples of 24 hours, without regards to daylight savings
  boundaries then both of the above date commands would return Wed
  Feb 29 23:00:00 CST 2012.
 
 Only if you start from the same point in time in both commands, which
 you didn't.

For an example always use a time in addition to a day.  Never default
to midnight.  Instead use 12:00 noon to avoid the DST problems.

  $ TZ=US/Mountain date -R -d 'last Thursday'
  Thu, 22 Mar 2012 00:00:00 -0600

That is problematic usage.  But specifying the time as 12:00 noon
solves the problem.

  $ TZ=US/Mountain date -R -d '12:00 last Thursday'
  Thu, 22 Mar 2012 12:00:00 -0600

Then doing calculations will be more reliable.

  $ TZ=US/Mountain date -R -d '12:00 last Thursday - 21 days'
  Thu, 01 Mar 2012 12:00:00 -0700

Note that I always use -R to obtain an unambiguous format.  Using the
default format isn't unambiguous as there are multiple timezones with
the same names.

Doing calculations on weeks and months have similar issues.  When
doing calculations on months I always work with the middle of the
month to avoid the difference in lenghts of months.

Generate a reference date in the middle of the month.

  $ date +%Y-%m-15
  2012-03-15

Use that date for month calculations.

  $ date --date=$(date +%Y-%m-15) -1 month +'Last month was %B.'
  Last month was February.

Please see the FAQ for more examples:

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

Unfortunately the human date parsing that was added to date is a
rather simplistic implementation.

Bob

bug#9718: bugs in `date` command?

[Voelker, Bernhard]

Jim Meyering wrote:

 Eric Blake wrote:
 ...
  As currently coded in the grammar, this is correct.  But if someone
  were willing to put forth the effort to update parsedate.y, as well as
  enhance the testsuite to cover things, it might be possible to improve
  the grammar to accept both common meanings of second depending on
  the context where it appears compared to the rest of the date.
 
 Just in case, I've marked this as wishlist.
 If you're interested, please add it to TODO.
 If not, please close this.

I don't know if it violates some standards, but I'd vote for
abbreviations like 1st, 2nd, 3rd, 4th, etc. which do not
interfere with the double meaning of second.
What do you think?

Have a nice day,
Berny

bug#9718: bugs in `date` command?

[Jim Meyering]

severity 9718 wishlist
tags 9718 + notabug
thanks

Eric Blake wrote:
...
 As currently coded in the grammar, this is correct.  But if someone
 were willing to put forth the effort to update parsedate.y, as well as
 enhance the testsuite to cover things, it might be possible to improve
 the grammar to accept both common meanings of second depending on
 the context where it appears compared to the rest of the date.

Just in case, I've marked this as wishlist.
If you're interested, please add it to TODO.
If not, please close this.

bug#9718: bugs in `date` command?

[Voelker, Bernhard]

Bryan Lee wrote:

 The term third wednesday seems to be evaluating incorrectly.
 
 glaive 12:24:56 [~]% date
 Mon Oct 10 12:24:59 EDT 2011
 
 glaive 12:24:59 [~]% date -d first wednesday
 Wed Oct 12 00:00:00 EDT 2011
 
 glaive 12:25:09 [~]% date -d second  wednesday
 Wed Oct 12 00:00:01 EDT 2011
 
 glaive 12:25:16 [~]% date -d third  wednesday
 Wed Oct 26 00:00:00 EDT 2011
 
 glaive 12:25:21 [~]% date -d fourth  wednesday
 Wed Nov  2 00:00:00 EDT 2011

Thank you for the report, however I don't see what's wrong.
I guess you meant second wednesday - which you probably expected
to display Oct 19th?

As 'second' is already used for the time unit 'second', it cannot
be used as an ordinal number for 2nd. The info text clarifies this
(info coreutils 'date invocation'):

 A few ordinal numbers may be written out in words in some contexts.
  This is most useful for specifying day of the week items or relative
  items (see below).  Among the most commonly used ordinal numbers, the
  word `last' stands for -1, `this' stands for 0, and `first' and `next'
  both stand for 1.  Because the word `second' stands for the unit of
  time there is no way to write the ordinal number 2, but for convenience
  `third' stands for 3, `fourth' for 4, `fifth' for 5, `sixth' for 6,
  `seventh' for 7, `eighth' for 8, `ninth' for 9, `tenth' for 10,
  `eleventh' for 11 and `twelfth' for 12.

Did you mean this?

Have a nice day,
Berny

bug#9718: bugs in `date` command?

[Eric Blake]

On 10/11/2011 01:31 AM, Voelker, Bernhard wrote:

Bryan Lee wrote:


The term third wednesday seems to be evaluating incorrectly.

glaive 12:24:56 [~]% date
Mon Oct 10 12:24:59 EDT 2011

glaive 12:24:59 [~]% date -d first wednesday
Wed Oct 12 00:00:00 EDT 2011

glaive 12:25:09 [~]% date -d second  wednesday
Wed Oct 12 00:00:01 EDT 2011


Indeed, this was parsed as first wednesday + 1 second


Thank you for the report, however I don't see what's wrong.
I guess you meant second wednesday - which you probably expected
to display Oct 19th?

As 'second' is already used for the time unit 'second', it cannot
be used as an ordinal number for 2nd.


As currently coded in the grammar, this is correct.  But if someone were 
willing to put forth the effort to update parsedate.y, as well as 
enhance the testsuite to cover things, it might be possible to improve 
the grammar to accept both common meanings of second depending on the 
context where it appears compared to the rest of the date.


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

bug#9718: bugs in `date` command?

[Bryan Lee]

The term third wednesday seems to be evaluating incorrectly.


glaive 12:24:56 [~]% date
Mon Oct 10 12:24:59 EDT 2011

glaive 12:24:59 [~]% date -d first wednesday
Wed Oct 12 00:00:00 EDT 2011

glaive 12:25:09 [~]% date -d second  wednesday
Wed Oct 12 00:00:01 EDT 2011

glaive 12:25:16 [~]% date -d third  wednesday
Wed Oct 26 00:00:00 EDT 2011

glaive 12:25:21 [~]% date -d fourth  wednesday
Wed Nov  2 00:00:00 EDT 2011

glaive 12:25:27 [~]% date -d fifth  wednesday
Wed Nov  9 00:00:00 EST 2011

glaive 12:25:34 [~]% date -d next  wednesday
Wed Oct 12 00:00:00 EDT 2011

glaive 12:25:41 [~]% date -d last  wednesday
Wed Oct  5 00:00:00 EDT 2011

glaive 12:25:46 [~]% date -d this  wednesday
Wed Oct 12 00:00:00 EDT 2011

glaive 12:33:39 [~]% date -d third  wednesday this month
Wed Oct 26 00:00:00 EDT 2011

glaive 12:34:11 [~]% date -d 3  wednesday
Wed Oct 26 00:00:00 EDT 2011

glaive 12:34:13 [~]% date -d 2  wednesday
Wed Oct 19 00:00:00 EDT 2011

glaive 12:34:28 [~]% date -d 1  wednesday
Wed Oct 12 00:00:00 EDT 2011

glaive 12:34:39 [~]% date -d 4  wednesday
Wed Nov  2 00:00:00 EDT 2011

bug#8782: date command

[Jim Meyering]

James Youngman wrote:
 On Thu, Jun 2, 2011 at 10:11 AM, Jim Meyering j...@meyering.net wrote:
 Pádraig Brady wrote:
 OK how about I put the last 3 or 4 examples from
 http://www.pixelbeat.org/cmdline.html#dates
 in an EXAMPLE section in the man page.

 Good examples.
 I like the idea.

 One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in
 the example.

Good idea.  That makes it immune to failure in a one hour interval
on the day before the spring DST transition.

bug#8782: date command

[Voelker, Bernhard]

Jim Meyering wrote:
 James Youngman wrote:

 One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in
 the example.

 Good idea.  That makes it immune to failure in a one hour interval
 on the day before the spring DST transition.

hmm, shouldn't the tomorrow handling be fixed then?

-- 
Berny

bug#8782: date command

[Jim Meyering]

Voelker, Bernhard wrote:
 Jim Meyering wrote:
 James Youngman wrote:

 One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in
 the example.

 Good idea.  That makes it immune to failure in a one hour interval
 on the day before the spring DST transition.

 hmm, shouldn't the tomorrow handling be fixed then?

Hi Voelker,

Fixed how?  To retry in that very unusual case?
Let's ignore that someone might depend on the current failure,
e.g., to locate a DST transition.

Note that tomorrow is equivalent to +1 day, aka +24 hours.

Upon retry would you use +23 hours or +25 hours?  Something else?

I don't think it's feasible to change it.
This is well documented in the FAQ, and probably in the manual, too.

bug#8782: date command

[Voelker, Bernhard]

Jim Meyering wrote:
 Voelker, Bernhard wrote:
 Jim Meyering wrote:
 James Youngman wrote:

 One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in
 the example.

 Good idea.  That makes it immune to failure in a one hour interval
 on the day before the spring DST transition.

 hmm, shouldn't the tomorrow handling be fixed then?

 Hi Voelker,

 Fixed how?  To retry in that very unusual case?
 Let's ignore that someone might depend on the current failure,
 e.g., to locate a DST transition.

that's BAD (tm) usage, IMHO

 Note that tomorrow is equivalent to +1 day, aka +24 hours.

 Upon retry would you use +23 hours or +25 hours?  Something else?

 I don't think it's feasible to change it.

I admit it's hard.
From the user's point of view, there's always a date 24 hours from now on.
And the user wants to know what date this would be ...

 This is well documented in the FAQ, and probably in the manual, too.

yes, it is. But as I'm following this ML for ~2 years now, this topic
has popped up several times. It seems there's room for improvement.

--
Bye,
Berny

bug#8782: date command

[Paul Eggert]

On 06/03/11 01:52, Voelker, Bernhard wrote:
 It seems there's room for improvement.

Absolutely.  All that we need is someone to volunteer to
specify exactly how to improve it, and to write the
documentation and code.  Unfortunately, this won't be
trivial.

bug#8782: date command

[Jim Meyering]

Voelker, Bernhard wrote:
 Jim Meyering wrote:
 Voelker, Bernhard wrote:
 Jim Meyering wrote:
 James Youngman wrote:

 One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in
 the example.

 Good idea.  That makes it immune to failure in a one hour interval
 on the day before the spring DST transition.

 hmm, shouldn't the tomorrow handling be fixed then?

 Hi Voelker,

 Fixed how?  To retry in that very unusual case?
 Let's ignore that someone might depend on the current failure,
 e.g., to locate a DST transition.

 that's BAD (tm) usage, IMHO

 Note that tomorrow is equivalent to +1 day, aka +24 hours.

 Upon retry would you use +23 hours or +25 hours?  Something else?

 I don't think it's feasible to change it.

 I admit it's hard.
From the user's point of view, there's always a date 24 hours from now on.
 And the user wants to know what date this would be ...

We can't change the fact that the spring DST transition
introduces a one-hour hole containing invalid times.
Whenever we tell date to use a time in such a hole,
date must diagnose it as invalid.

 This is well documented in the FAQ, and probably in the manual, too.

 yes, it is. But as I'm following this ML for ~2 years now, this topic
 has popped up several times. It seems there's room for improvement.

Making a technical change will be a challenge, to say the least.

People are learning that this hole can make date fail.
As I see it, education is the way to go.

bug#8782: date command

[Voelker, Bernhard]

Jim Meyering wrote:
 Voelker, Bernhard wrote:
 Jim Meyering wrote:
 Voelker, Bernhard wrote:
 Jim Meyering wrote:
 James Youngman wrote:

 One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in
 the example.

 Good idea.  That makes it immune to failure in a one hour interval
 on the day before the spring DST transition.

 hmm, shouldn't the tomorrow handling be fixed then?

 Hi Voelker,

 Fixed how?  To retry in that very unusual case?
 Let's ignore that someone might depend on the current failure,
 e.g., to locate a DST transition.

 that's BAD (tm) usage, IMHO

 Note that tomorrow is equivalent to +1 day, aka +24 hours.

 Upon retry would you use +23 hours or +25 hours?  Something else?

 I don't think it's feasible to change it.

 I admit it's hard.
From the user's point of view, there's always a date 24 hours from now on.
 And the user wants to know what date this would be ...

 We can't change the fact that the spring DST transition
 introduces a one-hour hole containing invalid times.
 Whenever we tell date to use a time in such a hole,
 date must diagnose it as invalid.

`date` is still a tool, so I feel it should reflect daily life
... I I don't feel I have a 1h gap in spring, do you? ;-)

bug#8782: date command

[Jim Meyering]

Voelker, Bernhard wrote:
...
 We can't change the fact that the spring DST transition
 introduces a one-hour hole containing invalid times.
 Whenever we tell date to use a time in such a hole,
 date must diagnose it as invalid.

 `date` is still a tool, so I feel it should reflect daily life
 ... I I don't feel I have a 1h gap in spring, do you? ;-)

I do notice it when I have one hour more or less to sleep.

I'd say that this tool does reflect daily life.  With date you have to
be careful about the DST transitions, just as you have to adjust clocks
twice a year.

bug#8782: date command

[Voelker, Bernhard]

Jim Meyering wrote:
 Voelker, Bernhard wrote:
 ...
 We can't change the fact that the spring DST transition
 introduces a one-hour hole containing invalid times.
 Whenever we tell date to use a time in such a hole,
 date must diagnose it as invalid.

 `date` is still a tool, so I feel it should reflect daily life
 ... I I don't feel I have a 1h gap in spring, do you? ;-)

 I do notice it when I have one hour more or less to sleep.

admitted.

 I'd say that this tool does reflect daily life.  With date you have to
 be careful about the DST transitions, just as you have to adjust clocks
 twice a year.

so in the night where the DST transition takes place, imagine you get
up to go to the toilet because you drank to much coffee the evening
before ... right in the hour where DST transition happens:
isn't there a `date`?
Or the other way round: how many hours do you have to left to sleep
until 8am?

The situation with date sounds like there is an hour once per year
when no date exists, but this is not true.

bug#8782: date command

[Ruediger Meier]

On Friday 03 June 2011, Voelker, Bernhard wrote:
 so in the night where the DST transition takes place, imagine you get
 up to go to the toilet because you drank to much coffee the evening
 before ... right in the hour where DST transition happens:
 isn't there a `date`?
 Or the other way round: how many hours do you have to left to sleep
 until 8am?

 The situation with date sounds like there is an hour once per year
 when no date exists, but this is not true.

There was no 2011-05-27 02:01:00 in Germany.
I am 100% sure nobody in Germany was on toilet on at this time.

At this date if you go at 01:59:00 and come back at 03:02:00 then you 
where 3 minutes on toilet but you was not at 2:01:00 because this time 
simply does not exist at this day.

This works as expected:

$ export TZ=Europe/Berlin

$ date -d 2011-03-27 02:01:00
date: invalid date `2011-03-27 02:01:00'

$ date -d 2011-03-26 02:01:00 tomorrow
Sun Mar 27 03:01:00 CEST 2011

cu,
Rudi

bug#8782: date command

[Pádraig Brady]

On 02/06/11 00:39, Jesse Gordon wrote:
 
 
 On 6/1/2011 4:12 PM, Pádraig Brady wrote:
 On 01/06/11 18:11, Rick Stanley wrote:
 The date command is very useful.  A lot of features and options which I
 take advantage of as I need them.  Every once in a while I need to use
 the command to convert a UNIX Epoch Date to a normal date, so I attempt
 to use the command as:

 date -d 1306947372

 Which results in the error message, date: invalid date `1306947372'.

 Neither 'date --help' or 'man date' shows that the command should have
 been written as:

 date -d @1306947372

 I needed to do a Google search to see what I was doing wrong. (My memory
 is not as good as it used to be!) ;^)

 I don't know why this ('@') is needed, since the date command recognizes
 many different date formats without specifying the format. For
 completeness of the help and man page, please add a line explaining that
 when passing a UNIX Epoch Date to the -d option, you need to prefix the
 date with a '@'.

 Thank you for your time and consideration!
 You need the '@' to disambiguate. Consider fir example:

   date --date=1243
   date --date=@1234

 Unfortunately the date input formats are many and varied,
 and I don't think it's worth getting specific in the man page.
 The man page currently says:

 The date string format is more complex than is easily documented
 here but is fully described in the info documentation.

 So I'll close this as adequately documented.

 thanks,
 Pádraig.
 
 Jumpin' whale gills!

Well when you put it like that :)

 I wish I'd known about the -d @ function! I ended
 up writing my own in Perl utility just to convert epochs to dates.
 
 I'm with Rick on this one. Date supports so many different date formats
 without any special arbitrary characters designating the format. The
 average sys admin just assumes the most simple date format in the world
 would also work the same way.
 
 Since -d @1234 is so useful, and since it uncharacteristically requires
 an arbitrary prefix code, I think that it would be a very good to put it
 in all forms of documentation, even where the dozens of other obvious
 uses are not documented.

OK how about I put the last 3 or 4 examples from
http://www.pixelbeat.org/cmdline.html#dates
in an EXAMPLE section in the man page.

There was also a recent report from RMS that
the date input formats wrt TZ were a bit buried.

cheers,
Pádraig.

bug#8782: date command

[Jim Meyering]

Pádraig Brady wrote:
...
 Jumpin' whale gills!

 Well when you put it like that :)

Heh ;-)  I had the same reaction.

 I wish I'd known about the -d @ function! I ended
 up writing my own in Perl utility just to convert epochs to dates.

 I'm with Rick on this one. Date supports so many different date formats
 without any special arbitrary characters designating the format. The
 average sys admin just assumes the most simple date format in the world
 would also work the same way.

 Since -d @1234 is so useful, and since it uncharacteristically requires
 an arbitrary prefix code, I think that it would be a very good to put it
 in all forms of documentation, even where the dozens of other obvious
 uses are not documented.

 OK how about I put the last 3 or 4 examples from
 http://www.pixelbeat.org/cmdline.html#dates
 in an EXAMPLE section in the man page.

Good examples.
I like the idea.

bug#8782: date command

[Pádraig Brady]

I'm going with these 3.
It's a bit tricky to align --help and man output,
but this isn't too bad I think.

cheers,
Pádraig.

From 9a7a5d114388342a86f7dc9ade7f69b70624e3fe Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Thu, 2 Jun 2011 13:00:18 +0100
Subject: [PATCH] doc: add examples to date --help

* src/date.c (usage): Add examples for TZ handling,
and seconds since epoch parsing, neither of which
were mentioned in the man page until now.

Suggested-by: Rick Stanley rstan...@rsiny.com
---
 src/date.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/src/date.c b/src/date.c
index 61d4818..6439d16 100644
--- a/src/date.c
+++ b/src/date.c
@@ -236,6 +236,18 @@ then an optional modifier, which is either\n\
 E to use the locale's alternate representations if available, or\n\
 O to use the locale's alternate numeric symbols if available.\n\
 ), stdout);
+  fputs (_(\
+\n\
+Examples:\n\
+Convert seconds since the epoch (1970-01-01 UTC) to a date\n\
+  $ date --date='@2147483647'\n\
+\n\
+Show the time on the west coast of the US (use tzselect(1) to find TZ)\n\
+  $ TZ='America/Los_Angeles' date\n\
+\n\
+Show the local time for 9AM next Friday on the west coast of the US\n\
+  $ date --date='TZ=\America/Los_Angeles\ 09:00 next Fri'\n\
+), stdout);
   emit_ancillary_info ();
 }
   exit (status);
-- 
1.7.5.2

bug#8782: date command

[Jim Meyering]

Pádraig Brady wrote:
 I'm going with these 3.
 It's a bit tricky to align --help and man output,
 but this isn't too bad I think.

Thanks.

 Subject: [PATCH] doc: add examples to date --help

 * src/date.c (usage): Add examples for TZ handling,
 and seconds since epoch parsing, neither of which
 were mentioned in the man page until now.

s/were/was/

 Suggested-by: Rick Stanley rstan...@rsiny.com

Usually, I prefer to list only names in the commit log,
leaving the name-to-email mapping to THANKS.in, since a few
contributors have requested that no email address be used
or that a different one be substituted.
If it's in a vc'd file like THANKS.in we can adjust it.

Sometimes I'm impatient or lazy, and put the email address in the log.

No big deal either way.

 ---
  src/date.c |   12 
  1 files changed, 12 insertions(+), 0 deletions(-)

 diff --git a/src/date.c b/src/date.c
 index 61d4818..6439d16 100644
 --- a/src/date.c
 +++ b/src/date.c
 @@ -236,6 +236,18 @@ then an optional modifier, which is either\n\
  E to use the locale's alternate representations if available, or\n\
  O to use the locale's alternate numeric symbols if available.\n\
  ), stdout);
 +  fputs (_(\
 +\n\
 +Examples:\n\
 +Convert seconds since the epoch (1970-01-01 UTC) to a date\n\
 +  $ date --date='@2147483647'\n\
 +\n\
 +Show the time on the west coast of the US (use tzselect(1) to find TZ)\n\
 +  $ TZ='America/Los_Angeles' date\n\
 +\n\
 +Show the local time for 9AM next Friday on the west coast of the US\n\
 +  $ date --date='TZ=\America/Los_Angeles\ 09:00 next Fri'\n\
 +), stdout);
emit_ancillary_info ();
  }
exit (status);

bug#8782: date command

[James Youngman]

On Thu, Jun 2, 2011 at 10:11 AM, Jim Meyering j...@meyering.net wrote:
 Pádraig Brady wrote:
 OK how about I put the last 3 or 4 examples from
 http://www.pixelbeat.org/cmdline.html#dates
 in an EXAMPLE section in the man page.

 Good examples.
 I like the idea.

One tweak: use date -d 12:00 +1 day instead of date -d tomorrow in
the example.

James.

bug#8782: date command

[Rick Stanley]

The date command is very useful.  A lot of features and options which I
take advantage of as I need them.  Every once in a while I need to use
the command to convert a UNIX Epoch Date to a normal date, so I attempt
to use the command as:

date -d 1306947372

Which results in the error message, date: invalid date `1306947372'.

Neither 'date --help' or 'man date' shows that the command should have
been written as:

date -d @1306947372

I needed to do a Google search to see what I was doing wrong. (My memory
is not as good as it used to be!) ;^)

I don't know why this ('@') is needed, since the date command recognizes
many different date formats without specifying the format. For
completeness of the help and man page, please add a line explaining that
when passing a UNIX Epoch Date to the -d option, you need to prefix the
date with a '@'.

Thank you for your time and consideration!

Cheers!

Rick

-- 
RSI (Rick Stanley, Inc.)
(917) 822-7771
www.rsiny.com
Computer Systems Consulting
Linux  Open Source Specialists

bug#8782: date command

[Pádraig Brady]

On 01/06/11 18:11, Rick Stanley wrote:
 The date command is very useful.  A lot of features and options which I
 take advantage of as I need them.  Every once in a while I need to use
 the command to convert a UNIX Epoch Date to a normal date, so I attempt
 to use the command as:
 
 date -d 1306947372
 
 Which results in the error message, date: invalid date `1306947372'.
 
 Neither 'date --help' or 'man date' shows that the command should have
 been written as:
 
 date -d @1306947372
 
 I needed to do a Google search to see what I was doing wrong. (My memory
 is not as good as it used to be!) ;^)
 
 I don't know why this ('@') is needed, since the date command recognizes
 many different date formats without specifying the format. For
 completeness of the help and man page, please add a line explaining that
 when passing a UNIX Epoch Date to the -d option, you need to prefix the
 date with a '@'.
 
 Thank you for your time and consideration!

You need the '@' to disambiguate. Consider fir example:

 date --date=1243
 date --date=@1234

Unfortunately the date input formats are many and varied,
and I don't think it's worth getting specific in the man page.
The man page currently says:

The date string format is more complex than is easily documented
here but is fully described in the info documentation.

So I'll close this as adequately documented.

thanks,
Pádraig.

bug#8782: date command

[Bob Proulx]

Rick Stanley wrote:
 date -d 1306947372
 Which results in the error message, date: invalid date `1306947372'.
 
 Neither 'date --help' or 'man date' shows that the command should have
 been written as:
 
 date -d @1306947372
 
 I needed to do a Google search to see what I was doing wrong. (My memory
 is not as good as it used to be!) ;^)

I am sorry that you had such trouble with the date command.  The
documentation for date should be available along with the date
command.  As the man page says:

   The full documentation for date is maintained as a Texinfo
   manual.  If the info and date programs are properly installed
   at your site, the command

  info coreutils 'date invocation'

   should give you access to the complete manual.

If for some reason the manual is not available we can try to debug why
and try to help you get it going for you.

The latest manual is also available on the web.

  http://www.gnu.org/software/coreutils/manual/

Here is the relevant parts for your topic:

  
http://www.gnu.org/software/coreutils/manual/html_node/Date-input-formats.html#Date-input-formats

 I don't know why this ('@') is needed, since the date command recognizes
 many different date formats without specifying the format.

If the @ sign weren't there it would be ambiguous as to what you were
trying to ask for and it could break previous behavior.

How else would it be possible to tell the difference between these two
dates?

  $ date -R -d @20110101
  Fri, 21 Aug 1970 12:08:21 -0600

  $ date -R -d 20110101
  Sat, 01 Jan 2011 00:00:00 -0700

Those are quite different dates!

 For completeness of the help and man page, please add a line
 explaining that when passing a UNIX Epoch Date to the -d option, you
 need to prefix the date with a '@'.

The manual explains the input formats on at least ten different pages
of documentation!  That is very much too long to put in the --help
output of the command.  The --help is good for very terse hints for
when you already know how to use a command but is not well suited for
a user manual.  There just isn't space to describe all of the features
of a program there.  Neither is the man page which is extracted from
the --help output very well suited to it.  This is a bug but one that
was fixed a very long time ago by creating the full manual using a
medium that was designed for it.

Bob

bug#8782: date command

[Jesse Gordon]

On 6/1/2011 4:12 PM, Pádraig Brady wrote:

On 01/06/11 18:11, Rick Stanley wrote:

The date command is very useful.  A lot of features and options which I
take advantage of as I need them.  Every once in a while I need to use
the command to convert a UNIX Epoch Date to a normal date, so I attempt
to use the command as:

date -d 1306947372

Which results in the error message, date: invalid date `1306947372'.

Neither 'date --help' or 'man date' shows that the command should have
been written as:

date -d @1306947372

I needed to do a Google search to see what I was doing wrong. (My memory
is not as good as it used to be!) ;^)

I don't know why this ('@') is needed, since the date command recognizes
many different date formats without specifying the format. For
completeness of the help and man page, please add a line explaining that
when passing a UNIX Epoch Date to the -d option, you need to prefix the
date with a '@'.

Thank you for your time and consideration!

You need the '@' to disambiguate. Consider fir example:

  date --date=1243
  date --date=@1234

Unfortunately the date input formats are many and varied,
and I don't think it's worth getting specific in the man page.
The man page currently says:

The date string format is more complex than is easily documented
here but is fully described in the info documentation.

So I'll close this as adequately documented.

thanks,
Pádraig.


Jumpin' whale gills! I wish I'd known about the -d @ function! I 
ended up writing my own in Perl utility just to convert epochs to 
dates.


I'm with Rick on this one. Date supports so many different date 
formats without any special arbitrary characters designating the 
format. The average sys admin just assumes the most simple date 
format in the world would also work the same way.


Since -d @1234 is so useful, and since it uncharacteristically 
requires an arbitrary prefix code, I think that it would be a 
very good to put it in all forms of documentation, even where the 
dozens of other obvious uses are not documented.


Thanks  have a great day,

Jesse Gordon

bug#7997: Feature request for date command

[Richard Stallman]

For date input (using --date=STRING) you can use the TZ variable to
specify the input timezone.  Here is an example.

  $ date -R --date='TZ=Europe/Rome 2004-10-31 06:30'
  Sat, 30 Oct 2004 23:30:00 -0600

  $ TZ=America/New_York date -R --date='TZ=Europe/Paris 2004-10-31 
06:30'
  Sun, 31 Oct 2004 01:30:00 -0400

That does the job, but it is not documented in the manual.
Could you document it, and add these examples?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

bug#7997: Feature request for date command

[Richard Stallman]

It should be possible to specify a timezone such as
Europe/Rome for the date input.  That works in TZ
to control the output, so it should work in the input too.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

bug#7997: Feature request for date command

[Bob Proulx]

Richard Stallman wrote:
 It should be possible to specify a timezone such as
 Europe/Rome for the date input.  That works in TZ
 to control the output, so it should work in the input too.

For date input (using --date=STRING) you can use the TZ variable to
specify the input timezone.  Here is an example.

  $ date -R --date='TZ=Europe/Rome 2004-10-31 06:30'
  Sat, 30 Oct 2004 23:30:00 -0600

That produced an answer in my local timezone of US/Central.  This is
useful for converting dates.  Here is another example.

  $ TZ=America/New_York date -R --date='TZ=Europe/Paris 2004-10-31 06:30'
  Sun, 31 Oct 2004 01:30:00 -0400

That converted a datestamp from Europe/Paris to America/New_York.

Does this help?

Bob

bug#7331: Date command bug

[Bob Proulx]

Raymond Pete wrote:
 Thanks for the info Bob :-) I figured I missed something here.
 I see running my jobs just after midnight is probably not best.

I like running those types of calculations either at 12 noon or using
UTC.  Then the DST issues are avoided.

I also like using the 'date -R' format since it is RFC standard (used
in email and news) and unambiguous about timezones.  Otherwise I like
using %F %T %z for being compact, unambiguous, and sorts nicely.

I will go ahead and close the bug with this email then.

 Appreciate all the work you guys do!

The team enjoys hearing those nice words.  :-)

Bob

bug#7331: Date command bug

[Raymond Pete]

Hi,
I believe I have come across a small bug in the date command when daylight
savings time is in the process of being run.

Example:
date --set 7 NOV 2010
 --Sun Nov  7 00:00:01 EDT 2010

date --date=+1 day
--Sun Nov  7 23:00:40 EST 2010


It would appear in Eastern time zone case there is a small 2 hour window of
error here whereby the date command has set the zone before it is actually
supposed to be set. I have seen this with all time zone shifts. Noticed
first last weekend when BST went to GMT.

Could be a known bug.. if so, sorry to trouble you guys.

Best Regards,

Ray

bug#7331: Date command bug

[Bob Proulx]

Raymond Pete wrote:
 I believe I have come across a small bug in the date command when daylight
 savings time is in the process of being run.

Thank you for the report.  But what you are describing looks like
an incorrect expectation of behavior to me.

 date --set 7 NOV 2010
  --Sun Nov  7 00:00:01 EDT 2010

You don't need to actually set the date and mess with the system
clock.  Just use --date and have date interpret the date string.  It
would make for a more reliable example.

 date --date=+1 day
 --Sun Nov  7 23:00:40 EST 2010

I assume that EDT and EST here are US/Eastern DST and US/Eastern
standard time?  Better to use 'date -R' to produce numeric values that
are not ambiguous.

  $ TZ=US/Eastern date -R -d Sun, 07 Nov 2010 00:00:01 -0400 +1 day
  Sun, 07 Nov 2010 23:00:01 -0500

 It would appear in Eastern time zone case there is a small 2 hour window of
 error here whereby the date command has set the zone before it is actually
 supposed to be set. I have seen this with all time zone shifts. Noticed
 first last weekend when BST went to GMT.

I don't understand.  7 NOV 2010 doesn't have a time associated with
it and so the zero hour (midnight) is used.

  $ zdump -v US/Eastern | grep 2010
  US/Eastern  Sun Nov  7 05:59:59 2010 UTC = Sun Nov  7 01:59:59 2010 EDT 
isdst=1 gmtoff=-14400
  US/Eastern  Sun Nov  7 06:00:00 2010 UTC = Sun Nov  7 01:00:00 2010 EST 
isdst=0 gmtoff=-18000

November 7th at midnight is still within daylight savings time.  Then
you say +1 day which adds 24 hours to the current clock time and
produces a time that is 24 hours later but *after* US/Eastern has
changed to standard time.  Spring forward and Fall back.  If you
were expecting it to be midnight on the next day then you have
forgotten that there is an extra hour inserted in the Fall when the
clocks are turned back one hour.

 Could be a known bug.. if so, sorry to trouble you guys.

I see no bug here.  Please explain if I missed something.

See also this reference for more information:

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

Bob

bug#6236: Bug report in Date Command

[Bob Proulx]

Eric Blake wrote:
 This is a mailing list frequented by lots of readers.  I'm not David,
 but I can reply.

By coincidence I am not David either.  But will respond too anyway. :-)

 lijian 65631 wrote:
  When I input the comman 'date +%Y%m%d -d 1986-05-04 1 day' to get the
  next day of '1986-05-04', I get the result as below.
  
  Maybe it is a bug of Date command , Please help to find it, Thanks.
 
 Thanks for the report.  However, it is most likely the only bug here is
 your understanding of how date operates around daylight savings events:
 http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e

I am confident that this is related to daylight savings time and that
it is answered in the FAQ.  Not having seen any activity on this issue
for a while I am going to close it in the bug tracking system.  Please
feel free to follow up if it has not answered your questions and the
group will see and read your message and the bug tracker will keep
track of it for us.

Bob

bug#6236: Bug report in Date Command

[Eric Blake]

On 05/20/2010 08:07 PM, lijian 65631 wrote:
 Dear David,

This is a mailing list frequented by lots of readers.  I'm not David,
but I can reply.

 
 When I input the comman 'date +%Y%m%d -d 1986-05-04 1 day' to get the
 next day of '1986-05-04', I get the result as below.
 
 Maybe it is a bug of Date command , Please help to find it, Thanks.

Thanks for the report.  However, it is most likely the only bug here is
your understanding of how date operates around daylight savings events:
http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e

 This e-mail and its attachments contain confidential information from

It is considered poor netiquette to include employer disclaimers on mail
sent to publicly archived mailing lists, where the disclaimer is
rendered ineffective.  Consider using a personal account instead.

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



signature.asc
Description: OpenPGP digital signature

bug#6236: Bug report in Date Command

[lijian 65631]

Dear David,

 

When I input the comman 'date +%Y%m%d -d 1986-05-04 1 day' to get the
next day of '1986-05-04', I get the result as below.

Maybe it is a bug of Date command , Please help to find it, Thanks.



 

Regards,

 

 Lijian 65631
 Email:  mailto:jay...@huawei.com jay...@huawei.com
 Tel  : 13510271503  0755-28979991
 Dept : Consumer Service Development Dept, HS


-
This e-mail and its attachments contain confidential information from
HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any
use of the 
information contained herein in any way (including, but not limited to,
total or partial 
disclosure, reproduction, or dissemination) by persons other than the
intended 
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by 
phone or email immediately and delete it!

 

attachment: image002.jpg

date command

[Bernd Fehling]

Hi all,

while using the date command (date GNU coreutils 5.93)
it reports e.g.:
Fri Mar  5 13:01:52 UCT 2010

So why is it reporting UCT and not UTC ???
Is that a typo?

Regards
Bernd

Re: date command

[Eric Blake]

According to Bernd Fehling on 3/5/2010 6:04 AM:
 Hi all,
 
 while using the date command (date GNU coreutils 5.93)
 it reports e.g.:
 Fri Mar  5 13:01:52 UCT 2010
 
 So why is it reporting UCT and not UTC ???
 Is that a typo?

Most likely, it is being inherited from $TZ in the environment:

$ TZ=UTC date
Fri Mar  5 13:45:10 UTC 2010
$ TZ=UCT date
Fri Mar  5 13:45:13 UCT 2010

If it is a typo in your environment, then check your configuration files
(such as ~/.bashrc...) for who might have been setting it wrongly in the
first place.

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



signature.asc
Description: OpenPGP digital signature

Re: date command

[Bernd Fehling]

Hi Erik,

there is no TZ set.

# date
Fr Mär  5 13:59:12 UCT 2010

# date -u
Fr Mär  5 13:59:18 UTC 2010

Lets see...
OK, yes you are right its a typo in SuSe system setting:
SUSE LINUX 10.1 (X86-64)
tail /etc/sysconfig/clock

## Type:string(Europe/Berlin,Europe/London,Europe/Paris)
## ServiceRestart:  boot.clock
#
# Timezone (e.g. CET)
# (this will set /usr/lib/zoneinfo/localtime)
#
TIMEZONE=UCT
DEFAULT_TIMEZONE=Europe/Berlin


Thanks a lot for your help.

Regards
Bernd


Eric Blake schrieb:
 According to Bernd Fehling on 3/5/2010 6:04 AM:
 Hi all,

 while using the date command (date GNU coreutils 5.93)
 it reports e.g.:
 Fri Mar  5 13:01:52 UCT 2010

 So why is it reporting UCT and not UTC ???
 Is that a typo?
 
 Most likely, it is being inherited from $TZ in the environment:
 
 $ TZ=UTC date
 Fri Mar  5 13:45:10 UTC 2010
 $ TZ=UCT date
 Fri Mar  5 13:45:13 UCT 2010
 
 If it is a typo in your environment, then check your configuration files
 (such as ~/.bashrc...) for who might have been setting it wrongly in the
 first place.
 

DATE command

[Robert]

From time to time, I run into a situation where I'd like to know the 
elapsed time between events.  In theory, this is easily accomplished by 
converting the date/time of both events to seconds since the epoch, then 
performing several divisions by the appropriate factors.


That is, until you run into this kind of weirdness in which date groks 
CST, EDT and EST but throws up its hands at the thought of Central 
Daylight Time.


[...@madeleine ~]$ date -d Dec 21 2004   7:42 AM CDT +%s
date: invalid date `Dec 21 2004   7:42 AM CDT'
[...@madeleine ~]$ date -d Dec 21 2004   7:42 AM CST +%s
1103636520
[...@madeleine ~]$ date -d Dec 21 2004   8:42 AM EDT +%s
1103632920
[...@madeleine ~]$ date -d Dec 21 2004   8:42 AM EST +%s
1103636520
[...@madeleine ~]$

This is on a CentOS 5.4 machine, fully updated.

[...@madeleine ~]$ rpm -q coreutils
coreutils-5.97-23.el5_4.1.i386

My apologies if this has already been fixed upstream.

Re: DATE command

[Bob Proulx]

Robert wrote:
 That is, until you run into this kind of weirdness in which date groks  
 CST, EDT and EST but throws up its hands at the thought of Central  
 Daylight Time.

Thank you for the report.  But what you are seeing is not a bug in
date but is a misunderstanding of when daylight savings time is active
in your timezone.  DST is valid from April to October and December
uses standard time.  Therefore your use of DST in December is invalid.

You are better off using UTC in all such cases.  It avoids problems
with DST.  You are simply running into a DST problem.  Remember, that
DST is in place by Act Of Congress.  It isn't a technical problem. :-)

 [...@madeleine ~]$ date -d Dec 21 2004   7:42 AM CDT +%s
 date: invalid date `Dec 21 2004   7:42 AM CDT'

Right.  There is no such time.  It is invalid.  Date correctly reports
this to you.

  $ zdump -v US/Central | grep '200[45]'
  US/Central  Sun Apr  4 07:59:59 2004 UTC = Sun Apr  4 01:59:59 2004 CST 
isdst=0 gmtoff=-21600
  US/Central  Sun Apr  4 08:00:00 2004 UTC = Sun Apr  4 03:00:00 2004 CDT 
isdst=1 gmtoff=-18000
  US/Central  Sun Oct 31 06:59:59 2004 UTC = Sun Oct 31 01:59:59 2004 CDT 
isdst=1 gmtoff=-18000
  US/Central  Sun Oct 31 07:00:00 2004 UTC = Sun Oct 31 01:00:00 2004 CST 
isdst=0 gmtoff=-21600
  US/Central  Sun Apr  3 07:59:59 2005 UTC = Sun Apr  3 01:59:59 2005 CST 
isdst=0 gmtoff=-21600
  US/Central  Sun Apr  3 08:00:00 2005 UTC = Sun Apr  3 03:00:00 2005 CDT 
isdst=1 gmtoff=-18000
  US/Central  Sun Oct 30 06:59:59 2005 UTC = Sun Oct 30 01:59:59 2005 CDT 
isdst=1 gmtoff=-18000
  US/Central  Sun Oct 30 07:00:00 2005 UTC = Sun Oct 30 01:00:00 2005 CST 
isdst=0 gmtoff=-21600

As you can see CDT is not valid at any time in December.

You also see this by experimentation.

  $ TZ=US/Central date -d Dec 21 2004   7:42 AM CDT
  date: invalid date `Dec 21 2004   7:42 AM CDT'

  $ TZ=US/Central date -d Dec 21 2004   7:42 AM CST
  Tue Dec 21 07:42:00 CST 2004

Please see this reference for more information.

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

Bob