- Original Message -
> Ah, in that case week 53 is correct, no?
>
> $ export TZ=Australia/Sydney; date; date -d'last week'; date -d'last
> week' +%W
> Mon Jan 7 13:41:02 EST 2013
> Mon Dec 31 13:41:02 EST 2012
> 53
>
>
Paul, I
On 01/06/2013 06:18 PM, Tomas Dabašinskas wrote:
> The time zone I'm using is GMT+10 (Australian East Std time).
Ah, in that case week 53 is correct, no?
$ export TZ=Australia/Sydney; date; date -d'last week'; date -d'last week' +%W
Mon Jan 7 13:41:02 EST 2013
Mon Dec 31 13:41:02 EST 2012
53
- Original Message -
> Something odd with your time zone setting?
> As I write this, the current time is
> Sun Jan 6 20:59:42 EST 2013.
>
Paul,
Many thanks for getting back.
The time zone I'm using is GMT+10 (Australian East Std time).
I'm sorry, I should have clarified this in my bug
On 01/06/2013 03:48 PM, Tomas Dabašinskas wrote:
> $ date
> Mon Jan 7 09:46:19 EST 2013
Something odd with your time zone setting?
As I write this, the current time is
Sun Jan 6 20:59:42 EST 2013.
Hi,
I'm getting week number 53 when trying to get last week on Mon Jan 7 09:46:19
EST 2013:
$ date
Mon Jan 7 09:46:19 EST 2013
$ date -d'last week' +%W
53
Expecting to get week 1
Many thanks!
--
Tomas Dabašinskas | Engineering Content Services | Red Hat Asia Pacific
tag 13071 + notabug moreinfo
close 13071
thanks
Tuc at T-B-O-H wrote:
> Hi,
Hi! :-)
> Running into a problem with date and month...
Since you aren't really submitting a bug report but just asking
questions I am going to go ahead here and mark the accounting of the
bug as closed
Hi,
Running into a problem with date and month...
---
#!/bin/bash
function example {
rptdate=$(date +%Y-%m-%d -d "$1 -6 months")
echo "6 months ago from $1 is ${rptdate}"
}
example 2012-09-30
example 2012-1
Ohad Basan wrote:
> Hey
Hey back!
> Regarding 'date' command.
> the -d parameter doesn't know how to receive a european date format
> e.g. DD/MM/
I am assuming by "doesn't know how to receive" you mean it produces a
different result than one you
Hey
Regarding 'date' command.
the -d parameter doesn't know how to receive a european date format
e.g. DD/MM/
I believe that it is a bug.
thanks you
tag 12995 + notabug
close 12995
thanks
Blabla Quentin wrote:
> hello, I am an user of Xubuntu, and in the documentation (manual
> page) of _date_, I've red a small syntax error in the details of
> 'output format':
>
> if you write 'minute (00..59)' or 'hour (00..23)', I think you must
> write 'se
hello, I am an user of Xubuntu, and in the documentation (manual page)
of _date_, I've red a small syntax error in the details of 'output format':
if you write 'minute (00..59)' or 'hour (00..23)', I think you must
write 'second (00..59)' instead of 'second (00..60)' too.
regards
---+
1 row in set (0.00 sec)
Colleagues inform me that postgresql behaves this way also, alongside
python's mx.DateTime library (and ms-sql too).
Conversely, sqlite, php behave like 'date' :)
.../Nemo
--
-
tag 12772 notabug
thanks
On 10/31/2012 04:00 AM, Guido Ackermann wrote:
> Hello,
> today i discovered a bug in the programm "date" handling human readable
> timeformats.
> The bug:
>
> # date --version
> date (GNU coreutils) 8.5
>
> # export LC_ALL=&qu
tag 12772 + notabug moreinfo
thanks
Guido Ackermann wrote:
> today i discovered a bug in the programm "date" handling human
> readable timeformats.
Thank you for the bug report. And also thank you very much for
including the version you are using. However you are trippi
Hello,
today i discovered a bug in the programm "date" handling human readable
timeformats.
The bug:
# date --version
date (GNU coreutils) 8.5
# export LC_ALL="C" ;date
Wed Oct 31 10:57:06 CET 2012
# export LC_ALL="C" ;date -d"last month"
Mon Oct 1 11:5
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 e
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
tags 12162 - moreinfo
close 12162
thanks
I haven't seen a response to this in a month. Therefore I am closing
the ticket as resolved. If you have new information or clarification
please feel free to continue the discussion.
Bob
h only the month
and year to be presented. No "day" at all. The "A.I."
implied would be rather simple: it's begging to say "I don't
care about the Day, just deal with the Month [and Year] in
this equation."
By having just-this-much logic in GNU-date could
SciFi wrote:
> I am just a passerby here. But when I see these specific
> kinds of "errors", especially due to "month" usages, I always
> have a thought: How would we make GNU-date to operate on the
> Month Number Itself when we type "month" in the --d
John Mizell wrote:
> gnu date has incorrect date when using date math during a leap year
Thank you for the report. But this appears to be incorrect usage.
> Here are the steps to reproduce
Thank you very much for providing your reproducing steps. It makes
diagnosis easy. So many peo
gnu date has incorrect date when using date math during a leap year
Here are the steps to reproduce
[jmizell@backdoor ~]$ date "+%m%Y" --date='1 month ago'
072012
[jmizell@backdoor ~]$ date "+%m%Y" --date='5 month ago'
032012
[jmizell@backdoor ~]$
tags 12162 + moreinfo
thanks
Andris Pavenis wrote:
> Noticed problems with command date:
Thanks for the report. However I do not understand what problem you
are trying to report. Showing the output that you expected would
help.
> [apavenis@callisto Test]$ ./date-test.sh
> + date
>
Noticed problems with command date:
[apavenis@callisto Test]$ ./date-test.sh
+ date
Thu Aug 9 10:16:31 EEST 2012
+ date -d '2 weeks ago'
Thu Jul 26 10:16:31 EEST 2012
+ date -d 'thursday 2 weeks ago'
Thu Jul 26 00:00:00 EEST 2012
+ date -d 'next month'
Sun Sep 9 1
marking this as done.
>From bfda96e0ac5552bb1784f5e1dc311918ce077d50 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Thu, 5 Jul 2012 16:11:49 -0700
Subject: [PATCH 2/2] doc: document leap seconds better
* doc/coreutils.texi (touch invocation, Time conversion specifiers)
(Options for date, Examples of date): Index "leap secon
On 05/07/12 18:39, Eric Blake wrote:
> retitle 11866 date doesn't accept 61-sec. minutes
thank you for the correction.
> The command 'date' doesn't have any control over whether your system is
> configured to honor or ignore leap seconds. Some systems are
> in
retitle 11866 date doesn't accept 61-sec. minutes
tag moreinfo
thanks
On 07/05/2012 02:15 AM, Juergen Heine wrote:
> A positive leap second will be introduced at the end of June 2012.
> The sequence of dates of the UTC second markers will be:
>
> 2012 June 30, 23h 59m 59
Hello,
can you please do me a favor and correct the typo in the title?
don't -> doesn't
Thank you for the GNU system!
--
Mit freundlichen Grüßen / Sincerely
i. A. Juergen Heine
juergen.he...@qvs-deutschland.de
QVS GmbH
Lange Laube 18
D-30159 Hannover
http://www.qvs-deutschland.de
Tel: 05
UTC second markers will be:
2012 June 30, 23h 59m 59s
2012 June 30, 23h 59m 60s
2012 July 1, 0h 0m 0s
~snap~
The command 'date' doesn't calculate it.
Test:
$ date +%s -d "2012-06-30 23:59:60"
date: invalid date `2012-06-30 23:59:60'
Tested version:
date (GN
;> + AC_REQUIRE([AC_C_INLINE])
>
> Thanks, Bruno.
> Here's the complete patch on the gnulib side:
> (still to do in coreutils: NEWS, test and gnulib update)
>
> Subject: [PATCH] parse-datetime: fix failure to diagnose invalid input
>
> date -d "$(printf '\xb0&#x
ere's the complete patch on the gnulib side:
(still to do in coreutils: NEWS, test and gnulib update)
>From d8f90adf5f01512958b6da46bd5eea01294a434e Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 4 Jul 2012 12:58:07 +0200
Subject: [PATCH] parse-datetime: fix failure to diagnose invalid
Jim Meyering wrote:
> +static inline unsigned char to_uchar (char ch) { return ch; }
For the use of 'inline', one needs this too:
--- m4/parse-datetime.m4.orig Wed Jul 4 10:04:43 2012
+++ m4/parse-datetime.m4Wed Jul 4 10:04:36 2012
@@ -1,4 +1,4 @@
-# parse-datetime.m4 serial 19
+# pa
peter evans wrote:
> Thank you for closing this as "not a bug".
>
> So it is not a bug that date is unable to parse its own output in
> arbitrary locales.
> Indeed, it would "not be a bug" if it stopped and complained about
> it. That would be
> perfectly
Bob Proulx wrote:
...
> I updated the 'date' FAQ section with an example of this type of usage.
>
>
> http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e
Nice. Thanks, Bob!
Jim Meyering wrote:
> Andreas Schwab wrote:
> > Jim Meyering writes:
> >> To get the behavior you want (a nominally no-op date-setting command),
> >> you should use this instead:
> >>
> >> date -s "$(date '+%F %T.%N')"
>
Andreas Schwab wrote:
> Jim Meyering writes:
>
>> To get the behavior you want (a nominally no-op date-setting command),
>> you should use this instead:
>>
>> date -s "$(date '+%F %T.%N')"
>
> That fails to be a no-op during the ambigo
Jim Meyering writes:
> To get the behavior you want (a nominally no-op date-setting command),
> you should use this instead:
>
> date -s "$(date '+%F %T.%N')"
That fails to be a no-op during the ambigous end-of-dst period. Better
use an unambigous f
erver 1.2.3.4 offset -0.002628
> sec
> [root@x]# date
> 2012年 7月 2日 月曜日 16:14:10 JST
> [root@x]# date -s "`date`"
> 2012年 7月 2日 月曜日 20:12:00 JST
> [root@x]# ntpdate ntp.server
> 2 Jul 16:14:15 ntpdate[18856]: step time server 1.2.3.4 offset -14268.134688
> se
Eric Blake wrote:
> Patrick Castet wrote:
> > $ touch a0.a
> > $ touch -d "2102 03:04:05" a0.a
> > if you check with widows cmd, you get
> > a0.a is dated with 2102 04:04
> >
> > wich is not correct !
>
> Welcome to the joys of Microsoft's decision to store file timestamps
> with respe
tag 11798 notabug
thanks
On 06/27/2012 03:52 AM, Patrick Castet wrote:
> $ touch a0.a
> $ touch -d "2102 03:04:05" a0.a
Thanks for the report.
> if you check with widows cmd, you get
I assume you meant Windows, not widows.
>
> a0.a is dated with 2102 04:04
>
>
> wich is not corr
On 06/27/2012 02:52 AM, Patrick Castet wrote:
> touch -d "2102 03:04:05" a0.a
This works for me, on GNU/Linux:
$ touch -d "2102 03:04:05" a0.a
$ ls -l --full-time a0.a
-rw-r--r--. 1 eggert eggert 0 2000-01-02 03:04:05.0 -0800 a0.a
I expect the problem that you're having with Wind
bug-coreutils@gnu.org
Hi,
if you try this
$ touch a0.a
$ touch -d "2102 03:04:05" a0.a
you get
$ ls -la a0.a
-rw-r--r-- 1 dmi Aucun 0 2 janv. 2000 a0.a
AND
if you check with widows cmd, you get
C:\cygwin\tmp>dir
Le volume dans le lecteur C n'a pas de nom.
Le numéro de série du
amanda sabatini writes:
>
> Hi,
>
> The follow command does not work with the specifics date: 1986-10-25;
> 1987-10-25; 1989-10-15; 1992-10-25; 1991-10-20; 1995-10-15; 2006-11-05.
>
> date +%d --date="1986-10-25"
The date command never actually works on date
Hi,
The follow command does not work with the specifics date: 1986-10-25;
1987-10-25; 1989-10-15; 1992-10-25; 1991-10-20; 1995-10-15; 2006-11-05.
date +%d --date="1986-10-25"
Sincerely,
Amanda Sabatini Dufek
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 '
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 -
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 starte
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 i
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
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 consist
Eric Blake wrote:
> > "10:38 minute" or "12:38 minute" is not a time designation I have ever heard
> > in spoken nor written English.
>
> True, 'minute' in isolation, without a 'plus one' qualifier, is unusual;
> but we have to continue to parse it in isolation since scripts may now
> be relying o
On Wednesday 28 March 2012, Eric Blake wrote:
> On 03/28/2012 03:23 PM, Bruno Haible wrote:
> > Eric Blake wrote:
> >> the parser is faced with an ambiguity between:
> >>
> >> (11:38 +1) minute
> >> 11:38 (+1 minute)
> >
> > What is the first interpretation meant to mean?
>
> The time 11:38 in the
Eric Blake wrote:
> the parser is faced with an ambiguity between:
>
> (11:38 +1) minute
> 11:38 (+1 minute)
What is the first interpretation meant to mean?
"10:38 minute" or "12:38 minute" is not a time designation I have ever heard
in spoken nor written English.
If you ditch this interpretatio
On 03/28/2012 03:23 PM, Bruno Haible wrote:
> Eric Blake wrote:
>> the parser is faced with an ambiguity between:
>>
>> (11:38 +1) minute
>> 11:38 (+1 minute)
>
> What is the first interpretation meant to mean?
The time 11:38 in the timezone UTC+1, plus the unit represented by 'minute'.
> "10:38
On Wednesday 28 March 2012, Eric Blake wrote:
> [adding bug-gnulib]
>
> On 03/28/2012 06:39 AM, Stefan Karamuz wrote:
> > Please check the 2 linux commands:
> >
> > date -d "$(date +%F\ %H:%M:%S)" +%F\ %H:%M:%S
> > date -d "$(date +%F\ %H:%M
[adding bug-gnulib]
On 03/28/2012 06:39 AM, Stefan Karamuz wrote:
> Please check the 2 linux commands:
>
> date -d "$(date +%F\ %H:%M:%S)" +%F\ %H:%M:%S
> date -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S
>
> It's very confusing, because the
Please check the 2 linux commands:
date -d "$(date +%F\ %H:%M:%S)" +%F\ %H:%M:%S
date -d "$(date +%F\ %H:%M:%S) + 1 minute" +%F\ %H:%M:%S
It's very confusing, because the results of the two commands differ in
one hour and one minute, except of one minute only.
[~]$ d
tag 11098 notabug
thanks
On 03/26/2012 05:31 AM, Hugo Guérineau wrote:
> Dear Mister, Madam,
>
> I'm writing to report a date computation problem.
>
> The command "date --date='yesterday' +%Y-%m-%d" launched this morning
> between 0:00 am and 0:59 a
Dear Mister, Madam,
I'm writing to report a date computation problem.
The command "date --date='yesterday' +%Y-%m-%d" launched this morning
between 0:00 am and 0:59 am gives the wrong result:
root@serveur:> date --date='today' +%Y-%m-%d; date --date='
tag 11057 notabug
thanks
On 03/21/2012 11:26 AM, Morin, Rick wrote:
> Hello,
>
> I'm having an interesting time trying to get the following code to work using
> your coreutils date program. I'm trying to get the date for Wednesday of the
> current week. This is runn
Hello,
I'm having an interesting time trying to get the following code to work using
your coreutils date program. I'm trying to get the date for Wednesday of the
current week. This is running in a Korn shell on an AIX 5.3 (AIX 64) platform.
MDOW1=$(${SBIN}/date +%w)
let MDOW=$M
On 02/02/2012 12:25 AM, Wang, YuanTao wrote:
> $ date -d "2012-01-01 00:00:00" +%U
> 01
>
> but in "man date"
> %U week number of year, with Sunday as first day of week (00..53)
>
> Is it a bug?
No. As the manual (which has more detail) says,
"
$ date -d "2012-01-01 00:00:00" +%U
01
but in "man date"
%U week number of year, with Sunday as first day of week (00..53)
Is it a bug?
$ uname -r
2.6.18-128.1.6.el5xen
On Tue, Jan 10, 2012 at 07:12, Bob Proulx wrote:
> For you I would actually give you a login on one of my systems. But
> instead how about if I send you a 'date' that is backported to
> Squeeze? Even though you say you love-to-hate it? :-) Then you can
> play with
check. If
> you would like me to confirm now do you have a system with a recent
> GNU Tools that I could SSH into?
For you I would actually give you a login on one of my systems. But
instead how about if I send you a 'date' that is backported to
Squeeze? Even though you say you lo
On Mon, Jan 9, 2012 at 08:49, Bob Proulx wrote:
> GNU date didn't learn how to handle ISO-8601 until very recently.
> Your version 8.5 doesn't have that code yet. Here is the NEWS file
> entry for the change as it went into the recent 8.13 release.
>
Thanks, Bob. Have a gr
Dotan Cohen wrote:
> It seems that ISO-8601 formated dates are not properly handled by the
> date utility.
GNU date didn't learn how to handle ISO-8601 until very recently.
Your version 8.5 doesn't have that code yet. Here is the NEWS file
entry for the change as it went into
It seems that ISO-8601 formated dates are not properly handled by the
date utility. The date utility seems to erroneously add
timezone-shifting when using ISO-8601 dates. This example is fine (see
the date roundtrip to back where it started):
✈saturn:~$ date +%s -d "2006-12-31 22:00"
11
tag 10413 notabug
thanks
On 12/29/2011 11:02 AM, Vicente Pérez M wrote:
> How to repeat:
>
>
> date -d '2011-08-21 + 1 DAY' +%Y-%m-%d
> date -d '2010-10-10 + 1 DAY' +%Y-%m-%d
>
> These dates is just when change from normal time UTC-4 to dts UCT-
How to repeat:
date -d '2011-08-21 + 1 DAY' +%Y-%m-%d
date -d '2010-10-10 + 1 DAY' +%Y-%m-%d
These dates is just when change from normal time UTC-4 to dts UCT-3
result: invalid date
The same operation with --utc works fine.
date -d '2011-08-21 + 1 DAY' +%Y-%m-%d
Krzysztof Kowalski wrote:
> For a test I changed system time to 1997 and date utility returned 20
> century as well :)
Of course you know you don't need to change the system time to test
this. You can do it easily with date.
$ date -d '1997-01-01 12:00 UTC' +%C
19
Bob
gt; > 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, pl
ove
> 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.
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 1
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 [
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:0
On Wed, Sep 28, 2011 at 11:04:11PM +0200, Andreas Schwab wrote:
> Sandro Santilli writes:
>
> > On Wed, Sep 28, 2011 at 12:19:22AM +0200, Andreas Schwab wrote:
> >> Pádraig Brady writes:
> >>
> >> > $ TZ=Japan+1 date
> >>
> >>
Sandro Santilli writes:
> On Wed, Sep 28, 2011 at 12:19:22AM +0200, Andreas Schwab wrote:
>> Pádraig Brady writes:
>>
>> > $ TZ=Japan+1 date
>>
>> This is a well-formed POSIX timezone.
>
> Meaning UTC+1 ?
The timzone name has no meaning, only
y determine whether the current TZ
value is supported. So it's not clear how that warning
would be generated.
Also, lots of programs use TZ; it's not just "date".
On Wed, Sep 28, 2011 at 12:19:22AM +0200, Andreas Schwab wrote:
> Pádraig Brady writes:
>
> > $ TZ=GB-Eire+1 date
>
> A POSIX timezone name cannot have dashes.
Doesn't all these "can't have" and "undefined" specs mean
we do can warn or error o
On Tue, Sep 27, 2011 at 11:52:22PM +0200, Andreas Schwab wrote:
> Pádraig Brady writes:
>
> > On 09/27/2011 03:09 PM, Sandro Santilli wrote:
> >> I've been puzzled by date(1) giving weird results
> >> when setting TZ to values unknown by zoneinfo.
> >>
Pádraig Brady writes:
> $ TZ=GB-Eire+1 date
A POSIX timezone name cannot have dashes.
> $ TZ=Japan+1 date
This is a well-formed POSIX timezone.
> $ TZ=Japan date
This is a non-POSIX timezone that happens to match an Olson timezone.
Andreas.
--
Andreas Schwab, sch...@linux-m68
On 09/27/2011 10:47 PM, Andreas Schwab wrote:
> Pádraig Brady writes:
>
>> $ TZ=NZ+1 date # No zone reported
>
> This is undefined. A zone name in a POSIX time zone must have at least
> three letters.
I considered that, but it seems inconsequential in this case.
I&#x
Pádraig Brady writes:
> $ TZ=NZ+1 date # No zone reported
This is undefined. A zone name in a POSIX time zone must have at least
three letters.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for s
Pádraig Brady writes:
> On 09/27/2011 03:09 PM, Sandro Santilli wrote:
>> I've been puzzled by date(1) giving weird results
>> when setting TZ to values unknown by zoneinfo.
>>
>> As far as:
>>
>> $ TZ=Fake date
>> Tue Sep 27 14:06:32 Fa
On 09/27/2011 07:19 PM, Pádraig Brady wrote:
> On 09/27/2011 03:09 PM, Sandro Santilli wrote:
>> I've been puzzled by date(1) giving weird results
>> when setting TZ to values unknown by zoneinfo.
>>
>> As far as:
>>
>> $ TZ=Fake date
>> Tue Sep
On Tue, Sep 27, 2011 at 07:19:12PM +0100, Pádraig Brady wrote:
> On 09/27/2011 03:09 PM, Sandro Santilli wrote:
> > I've been puzzled by date(1) giving weird results
> > when setting TZ to values unknown by zoneinfo.
> >
> > As far as:
> >
> > $ TZ=
On 09/27/2011 03:09 PM, Sandro Santilli wrote:
> I've been puzzled by date(1) giving weird results
> when setting TZ to values unknown by zoneinfo.
>
> As far as:
>
> $ TZ=Fake date
> Tue Sep 27 14:06:32 Fake 2011
Yes, that is per POSIX.
One can specify info about
I've been puzzled by date(1) giving weird results
when setting TZ to values unknown by zoneinfo.
As far as:
$ TZ=Fake date
Tue Sep 27 14:06:32 Fake 2011
It would be more helpful if the command raised an error
or warning about "unknown" timezones rather than giving
rand
It has been a year in the bug tracker system without any response. So
I am assuming the issue is no longer relevant. Closing the bug.
Bob
Bob Proulx wrote:
> Sandoval, Juan wrote:
> > vhost01.dca.int: ~ % /usr/local/gnu/bin/date --date "7 days + 11-jul-2010"
> >
tag 9283 notabug
thanks
On 08/11/2011 04:52 AM, mike1@hsbcib.com wrote:
Here's what I found adding +1 days to a 2011-10-30
(BTW this is not a problem for any other date I tried)
Thanks for the report. However, this is not a bug, but a consequence of
daylight savings in your cu
My guess is that, in your time zone, 24 hours after midnight
on 10-30 is indeed 10-31, due to daylight-saving switch.
You can verify this by running 'date' without the '+' option.
Here's what I found adding +1 days to a 2011-10-30
(BTW this is not a problem for any other date I tried)
fut=$(date -d"2011-10-30" '+%F') ;
echo $fut
2011-10-30
fut=$(date -d"$fut +1 days" '+%F') ;
echo $fut
2011-10-30
fut=$(date -d"$fu
Bob Proulx wrote:
> Please see this FAQ entry for detailed explanation and hints on how to
> avoid this problem.
>
>
> http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e
Since there hasn't been any feedback on this bug since March I ass
you are asking.
>
> Possibly you are tripping up on a FAQ?
> http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e
>
> Please demonstrate what you typed, what 'date' actually output, and what
> you were expecting 'date' to output.
GbTS> Well, there's your answer. You were probably asking for a date/time that
GbTS> did not exist due to the daylight savings time skip.
OK, but maybe the error message should give more details, as it would
usually be very hard for the user to guess such a rare occurrence.
jida...@jidanni.org wrote:
> By the way, America is undergoing a Daylight Savings Time jump right
> about now.
Well, there's your answer. You were probably asking for a date/time that
did not exist due to the daylight savings time skip.
--
Benoît Knecht
ints the century, for
example 21. It turns out that it doesn't. From the documentation:
%C century; like %Y, except omit last two digits (e.g., 20)
I agree though that using the word "century" here is misleading.
> date (GNU coreutils) 8.5
> Copyright © 2010
On 06/24/2011 01:52 PM, Eric Blake wrote:
> %C does not mean the century in common parlance, rather, according to
> POSIX, it means:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html
>
>>
>> %C
>> Century (a year divided by 100 and truncated to an integer) as a decimal
tag 8930 notabug
thanks
> ~$ *date*
> vendredi 24 juin 2011, 20:32:50 (UTC+0200)
> ~$ *date +%C*
> 20
>
>
> *# 21st Century !*
>
Thanks for the report. However, this is not a bug.
%C does not mean the century in common parlance, rather, according t
401 - 500 of 1206 matches
Mail list logo
