date-command

[Anders.Persson]

 I´m running coreutils 6.9.92.4-f088d-dirty  (dirty??), and I found a bug. I´m 
using the function of asking for a date some month ago. For example date 
--date="-2 month" +%Y%m%d. And when doing that on the first o june 01:00, I got 
the answer march 31, instead of April 1. I´ve checked som alternatives, like 
using nn month ago, instead of a negative number of month. But the result is 
the same. I got the same result if I asked about 12 or 14 month ago, but not 13 
or 11 month ago. It seems like if I ask  for a number of month back, it should 
always be the first of a month, But it isn´t. It could be the 31 or 3 of a 
month. Obviously depending of the number of days in the  months. It doesn´t 
count a number of month backwords. But a number of days, not calculating 
correctly how many days the different days have.  It seems to happen on a even 
number of month back.

 This is my first bug-report, so I hope I reported in a good manner.

/Anders  

Anders Persson 
Softronic Dokumenthantering AB 
070 - 584  3278
930 90 Arjeplog
[EMAIL PROTECTED]

  

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

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.

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

[Jim Meyering]

Felix Joussein <[EMAIL PROTECTED]> wrote:
> Hello Jim,

Hi Felix,

Thanks for the report.
It would probably have been resolved by now (10 hours later)
if you had sent it to the bug-reporting/discussion list rather
than just to me.  I'm forwarding it there now.

> within a project which is related to date/time opeartions I was about to
> rebuild system which was originaly based on Ret Hat 7.2 Linux to
> Debian/Etch.
> The project is almost done when I tried out the following with the date
> command from Debian/Etch:
> date -s '01/31/2008 14:20:60' -> Invalid date
> using the date command from the former Red Hat 7.2
> date -s '01/31/2008 14:20:60' -> Working
>
> Apperarently the new date command from Debian/Etch which is of the version
> /bin/date --version
> date (GNU coreutils) 5.97
> Copyright © 2006 Free Software Foundation, Inc.
> Dieses Programm ist freie Software. Sie dürfen Kopien davon weitergeben
> gemäß
> der GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
> Es gibt KEINERLEI GARANTIE, so weit das Gesetz es erlaubt.
>
> Geschrieben von David MacKenzie.
>
> has problems to interpret the 60th second, whereas the date command from
> Red Hat 7.1, which is of the version
>
> /usr/local/bin/date --version
> date (GNU sh-utils) 2.0
> Written by David MacKenzie.
>
> Copyright (C) 1999 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> does it perfectly.
>
> Basicaly the goal ist, to set back the time at a certain moment for 1
> Second. It's all about the leap-second which might be set every last
> second of the 31th of dec. or 30th of june...
> Doing this with the new date command the time is set back to 2 seconds
> rather then one... with the old date command using the minute's 60st
> second a step-back for one second is possible.
>
> Do you have any idea how this may happen?
>
> Regads and thanks for your help,
>
> --
> mit freundlichen Grüßen
>
> Felix Joussein
>
> Integrated Network Design
> Firma Felix Joussein
> [EMAIL PROTECTED]


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

Re: date command

[James Youngman]

On Feb 1, 2008 8:24 AM, Jim Meyering <[EMAIL PROTECTED]> wrote:

> > Basicaly the goal ist, to set back the time at a certain moment for 1
> > Second. It's all about the leap-second which might be set every last
> > second of the 31th of dec. or 30th of june...
> > Doing this with the new date command the time is set back to 2 seconds
> > rather then one... with the old date command using the minute's 60st
> > second a step-back for one second is possible.
> >
> > Do you have any idea how this may happen?

Leap seconds occur in UTC.   They are often handled by the kernel (if
at all) and a common way to do this is to run an NTP client.See
also http://www.cis.udel.edu/~mills/leap.html

It is normally not necessary to introduce a manual adjustment with
"date" in order to maintain synchronisation.

James.


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

Re: date command

[Felix Joussein]

Hello James,

thank you for your brief answer.
Basically I am aware of what you said, but as I am operating an NTP
Server which get it's timescale directly from an ATOM clock via the
serial interface, which makes it to a STRATUM 1 server, I have to set
the leap second manually by date command or similar to push forward the
ntp-server timescale for this one second when ever the IERS announces a
leap second.
The prior system was running on a Red Hat 7.2 where the date command was
able to set the 60th second... unfortunately the version of the
coreutils which is shipped in debian/etch does not.
I'm helping myself now by using the old date command from the Red Hat
distribution which seams to work for my needs but never then less:
Why has a 8 year old version of date a feature, which it's actual
version doesn't have? I cannot imagine, that the code which is necessary
to set the 60th second would blow up the code that much, that the date
project-team decides to blow out that code...
I'm really confused about that fact!

Thank you for helping me with my problem.

many regards,

Felix Joussein

James Youngman schrieb:
> On Feb 1, 2008 8:24 AM, Jim Meyering <[EMAIL PROTECTED]> wrote:
>
>   
>>> Basicaly the goal ist, to set back the time at a certain moment for 1
>>> Second. It's all about the leap-second which might be set every last
>>> second of the 31th of dec. or 30th of june...
>>> Doing this with the new date command the time is set back to 2 seconds
>>> rather then one... with the old date command using the minute's 60st
>>> second a step-back for one second is possible.
>>>
>>> Do you have any idea how this may happen?
>>>   
>
> Leap seconds occur in UTC.   They are often handled by the kernel (if
> at all) and a common way to do this is to run an NTP client.See
> also http://www.cis.udel.edu/~mills/leap.html
>
> It is normally not necessary to introduce a manual adjustment with
> "date" in order to maintain synchronisation.
>
> James.
>
>
>   


-- 
mit freundlichen Grüßen

Felix Joussein

Integrated Network Design
Firma Felix Joussein
[EMAIL PROTECTED]

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

Re: date command

[Philip Rowlands]

On Fri, 1 Feb 2008, Felix Joussein wrote:


Basically I am aware of what you said, but as I am operating an NTP
Server which get it's timescale directly from an ATOM clock via the
serial interface, which makes it to a STRATUM 1 server, I have to set
the leap second manually by date command or similar to push forward the
ntp-server timescale for this one second when ever the IERS announces a
leap second.
The prior system was running on a Red Hat 7.2 where the date command was
able to set the 60th second... unfortunately the version of the
coreutils which is shipped in debian/etch does not.
I'm helping myself now by using the old date command from the Red Hat
distribution which seams to work for my needs but never then less:
Why has a 8 year old version of date a feature, which it's actual
version doesn't have? I cannot imagine, that the code which is necessary
to set the 60th second would blow up the code that much, that the date
project-team decides to blow out that code...


Hi Felix,

I simply don't think it's possible to use date for the stated goal. 
There is no built-in historical knowledge of leap seconds for the 
purposes of allowing the occasional ":60" setting - incidentally, the 
example given "01/31/2008 14:20:60" was not an official leap second.


These notes explain how the underlying timers are incremented through a 
leap second:

http://www.cis.udel.edu/~mills/leap.html

Once a leap second has passed, effectively the system forgets it ever 
happened. The following wall-clock timestamps were actually 11 seconds 
apart, but date shows only a 10 second gap.


$ date -u -d '2005-12-31 23:59:55' +%s
1136073595
$ date -u -d '2006-01-01 00:00:05' +%s
1136073605

The right way (I think) for what you're trying to do is obtain in 
advance a copy of the "leapseconds" file supported by ntpd; latest 
version here:


http://www.cis.udel.edu/~mills/leap-seconds.3331497600

Stratum-1 clocks need to be told when a leap second is approaching, to 
propagate this information through the leap "bits" to their configured 
slaves. If this is not done correctly the machines will not march in 
step, and the way the ntp protocol works doesn't allow for spot fixes at 
or after a discontinuity; the semi-random polling interval would almost 
guarantee your population of machines would learn of (and apply) the 
change at different times.



Cheers,
Phil


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

Re: date command

[Paul Eggert]

Felix Joussein <[EMAIL PROTECTED]> writes:

 Basicaly the goal ist, to set back the time at a certain moment for 1
 Second. It's all about the leap-second which might be set every last
 second of the 31th of dec. or 30th of june...

But the stated time stamp (01/31/2008 14:20:60) is not a leap second.
So it doesn't seem to be an example of the goal that you were trying
to accomplish.

Most systems don't support leap seconds, but if you are on a system
that does support them, then leap-second time stamps should continue
to work.  (If they don't work, please report them as a bug.)  However,
invalid time stamps like 01/31/2008 14:20:60 are not supported.  Such
strings used to have an (undocumented) behavior, but the behavior was
inconsistent and the inconsistencies caused some other problems, so we
thought it better to simply reject them.


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

Re: date command

[Philip Rowlands]

[ Re-adding bug-coreutils, so the mailing list archives get the benefit 
of the whole discussion ]


On Wed, 27 Feb 2008, Felix Joussein wrote:


thank your for your detailed answers.
since we're talking about time, and I was quiet busy the past 4 weeks and 
didn't have time to continue, I'm now about to resume my work. At this point I 
know everything about the leap-second that is written about on the ntpd 
homepage
So one precise information is still missing: Where do I have to install the 
leap-second.XX file? I'd copied it to /etc/ntp/leap-second..

Is this the right place?


The information is missing where? Did you check the ntpd documentation?
http://www.cis.udel.edu/~mills/ntp/html/miscopt.html

Please see the "leapfile" configuration option.


Cheers,
Phil


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

Re: date-command

[Bob Proulx]

[EMAIL PROTECTED] wrote:
> I´m running coreutils 6.9.92.4-f088d-dirty (dirty??),

"dirty" means that you are running from a git version control system
checkout of the code with uncommitted changes and not from an official
upstream distribution image.  That is okay.

> and I found a bug. I´m using the function of asking for a date some
> month ago. For example date --date="-2 month" +%Y%m%d. And when
> doing that on the first o june 01:00, I got the answer march 31,
> instead of April 1.

This is a known limitation.  The date processing code was incorporated
from a best-effort module that isn't 100% precise.  Months are fuzzy
quantities that vary in duration.  The operation of the plus and minus
month adjustments is to add or subtract a month's worth of days.
However this may land the result on an invalid date or on a date that
isn't into the previous month.

See the Coreutils documentation section "Relative items in date
strings" where this is described in more detail.  Expecially this
section:

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

   $ date -R
   Thu, 31 Jul 2003 13:02:39 -0700
   $ date --date='-1 month' +'Last month was %B?'
   Last month was July?
   $ date --date="$(date +%Y-%m-15) -1 month" +'Last month was %B!'
   Last month was June!

> It doesn´t count a number of month backwords. But a number of days,
> not calculating correctly how many days the different days have.

That is correct.  The recommended proceedure is to do month
calculations based upon the middle of the month.  Normally I first get
the time once with date and then use it as a reference time thereafter
so as to avoid issues with crossing midnight on a month boundary.

>  This is my first bug-report, so I hope I reported in a good manner.

Your report was great!

Bob


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

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

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

Bug in date command

[Toni]

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

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

bug-coreutils date command

[Richard Narum]

FYI, 

I'm not sure if you would call this a bug or not but I'm wondering why the GNU 
date command doesn't have the correct time adjustment for daylight savings from 
years past on its output when using an input date string to generate its 
output. It seems to have the current rules applied to all dates, i.e. in 2007 
daylight savings starts second Sunday in March and ends the first Sun in 
November while in 2006 it should start on the first Sunday in April ending the 
last Sunday in October. I live in the Central Timezone, TZ=CST6CDT, and have 
found that the time adjustments for previous years don't line up to their 
proper dates. It doesn't seem like there is any daylight savings rules based on 
year. The site http://aa.usno.navy.mil/faq/docs/daylight_time.php has some 
reference to the rules I am talking about. 

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

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

$ export TZ=CST6CDT 
$ i=$(date --date="01/01/2005" +%s) 
$ while true; do date --date="1970-01-01 00:00:00 $i sec UTC"; ((i=$i+86400)); 
done 

Summary: 

Sun Mar 12 00:00:00 CST 2006 (should be Sun Apr 2 00:00:00 CST 2006) 
Mon Mar 13 01:00:00 CDT 2006 (should be Mon Apr 3 01:00:00 CDT 2006) 
Sun Nov 5 01:00:00 CDT 2006 (should be Sun Oct 29 01:00:00 CDT 2006) 
Mon Nov 6 00:00:00 CST 2006 (should be Mon Oct 30 00:00:00 CST 2006) 

Sun Mar 11 00:00:00 CST 2007 
Mon Mar 12 01:00:00 CDT 2007 
Sun Nov 4 01:00:00 CDT 2007 
Mon Nov 5 00:00:00 CST 2007 

What I got out of the above article the rules would be something like the 
following. 

1974 starts Jan 6 ends last Sun in Oct 
1975 starts Feb 23 ends last Sun in Oct 
1976-1986 starts last Sun in Apr ends last Sun in Oct 
1987-2006 starts first Sun in Apr ends last Sun in Oct 
2007- starts second Sun in Mar ends first Sun in Nov 

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

Thanks, 

Richard Narum, Design/CAD Systems Engineer 
Applied Engineering, Inc. 
1025 Airport Road 
Bismarck, ND 58504 
Phone: 701-255-1137 
Fax: 701-255-1046 
www.ae-solutions.com 
-- 
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Problem with Date Command

[Dameon G. Rogers]

Bug-coreutils,

   I would like to report a problem with the *date* command:

date +%C

does not function properly.  It says it displays the current 
century but the/ definition /of century means that we are in the 21st 
not the 20th.  Either the command needs to be changed or the man page 
needs to be changed to express what the command actually does.  Any 
assistance would be appreciated.


D. Rogers

--
***

President - Association of Computing Machinery
[EMAIL PROTECTED]
[EMAIL PROTECTED]

***



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

Bug in date command

[Bob Kline]

The date command reports the wrong ISO week number in some cases.  For
example:

$ date -d 2008-12-31 +%Y%V
200801

Clearly the last day of the year can't be in the first week of that
year.

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



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

bug in date-command

[Bas Mijling]

Hi,

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

e.g. for 25 October 2008

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

which gives as result the next day: 20081026


This works perfect for all dates I used so far, apart from a (strangely 
enough) 20081026


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

returns the same datecode: 20081026


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

Regards,

Bas Mijling


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

bug in date command

[duncan brown]

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

-d

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

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



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

problems with date command

[Alaw Guo]

Hello, 

I have systems running RedHat 9, Fedora Core 1 and 2, and on all of
them I'm having trouble with the date program.

When I give the command:

  date --date="1/1/1970 00:00:`date +"%s"`"

Shouldn't this give me the current time?

instead, on a RedHat 9 and a Fedora Core 1 system I get:

  [EMAIL PROTECTED] bin]# date ; date --date="1/1/1970 00:00:`date +"%s"`"
  Sun Jul 25 12:49:32 PDT 2004
  Sun Jul 25 20:49:32 PDT 2004

and on a Fedora Core 2 system I get:

  [EMAIL PROTECTED] cgi-bin]# date ; date --date="1/1/1970 00:00:`date +"%s"`"
  Sun Jul 25 12:50:44 PDT 2004
  Thu Jan  1 00:00:59 PST 1970

It's an uneasy feeling when you can't rely on the time.
Thanks for listening.

--alaw


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

bug in date command

[Prog piR]

date +%^B gives the month in capital letters

but in french august is "août", and the accentued letter is not capitalized

date +%^B gives AOûT instead of AOÛT

In addition, is there any option to have lowercase ?

Thanks

bug#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#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?= 
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 
---
 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 

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

[Jim Meyering]

James Youngman wrote:
> On Thu, Jun 2, 2011 at 10:11 AM, Jim Meyering  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

[Ruediger Meier]

On Friday 03 June 2011, Ruediger Meier wrote:
> There was no "2011-05-27 02:01:00" in Germany.
Typo, I ment 2011-03-27.

cu,
Rudi

error in date command

[Adam Miller]

Hi,

  According to the man page, /bin/date +%x should report the 
date in the following format: mm/dd/yy


  However, when run in bash the command above reports the date in the 
following format: mm/dd/


  I have been calling a bash script in through cron, which reports the 
date as it should.  So why would running the command in bash be different?


My machine:
Fedora Core release 4 (Stentz) x86_64
Kernel 2.6.15
coreutils-5.2.1-48
bash-3.0-31

Please cc me in the response, I am not currently subscribed to the mailing 
list.  Thanks!


Cheers,
Adam Miller



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

Re: Bug in date command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

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

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

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

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

iD8DBQFHRRKw84KuGfSFAYARAqyPAJ4iR8cIpHCH9skbABJdAa2LiMRjagCg0ojS
gZ03kXg7uvh3Xlk98JpimFE=
=8ynR
-END PGP SIGNATURE-


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

Re: Bug in date command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

[Adding the last-documented Spanish translation team]

According to Toni on 11/21/2007 10:32 PM:
> According to Toni on 11/21/2007 2:28 PM:
>> date +%R does not show seconds
>
> Not a bug, since that is what it is documented to do:
>
> $ date --help | grep %R
>   %R   24-hour hour and minute; same as %H:%M
>


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

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

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

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

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


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

Re: Bug in date command

[Santiago Vila]

On Wed, 21 Nov 2007, Eric Blake wrote:

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

Indeed. Thanks for the reminder.


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

Re: bug-coreutils date command

[Philip Rowlands]

On Mon, 3 Dec 2007, Richard Narum wrote:

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


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


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



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

$ export TZ=CST6CDT


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


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


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


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



Cheers,
Phil


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

Re: bug-coreutils date command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

Checking cygwin packages is as simple as:

cygcheck -c tzcode

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

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

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

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


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

Re: bug-coreutils date command

[Paul Eggert]

TZ=CST6CDT is not a standard setting.  On some hosts, it consults the
tz database and will give you "generic" Central Time rules.  On others
it will consult a hardwired internal algorithm and will likely mess up.
You'd be better off using a standard zoneinfo setting like
TZ='America/Chicago'.

This shouldn't have anything to do with coreutils; it's a C library issue.


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

Re: bug-coreutils date command

[Richard Narum]

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

Thanks again,

Rick
--

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

Checking cygwin packages is as simple as:

cygcheck -c tzcode

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

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

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

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



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

Re: Problem with Date Command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Dameon G. Rogers on 6/4/2008 10:09 PM:
| Bug-coreutils,
|
|I would like to report a problem with the *date* command:
|
| date +%C
|
| does not function properly.  It says it displays the current century

'date --help' (and thus the man page) defines what it is using as "century":

~  %C   century; like %Y, except omit last two digits (e.g., 21)

In other words, it is not the English definition, so much as (year % 100).
~ As the behavior of %C is specified by POSIX, about all we could do is
change the description - any proposed wordings that would make this more
clear to you?

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

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

iEYEARECAAYFAkhH1f4ACgkQ84KuGfSFAYAp+QCeO/bZzdf3bwtBkeCs64/37YlS
VPwAn0nuPgw0/QwgYja96Q0Hk5/0xjRL
=+wAK
-END PGP SIGNATURE-


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

Re: Problem with Date Command

[Philip Rowlands]

On Wed, 4 Jun 2008, Dameon G. Rogers wrote:


Bug-coreutils,

  I would like to report a problem with the *date* command:

date +%C

   does not function properly.  It says it displays the current 
century but the/ definition /of century means that we are in the 21st 
not the 20th.


The documentation does not state that %C is the ordinal century; in the 
manpage/--help output, we see:


  %C   century; like %Y, except omit last two digits (e.g., 21)
  %Y   year

and from the info documentation:

`%C'
 century.  This is like `%Y', except the last two digits are
 omitted.  For example, it is `20' if `%Y' is `2000', and is `-0'
 if `%Y' is `-001'.  It is normally at least two characters, but it
 may be more.

Either the command needs to be changed or the man page needs to be 
changed to express what the command actually does.  Any assistance 
would be appreciated.


I agree that until 2100, it would be better if the manpage gave "20" as 
the example, or no example at all, but the wording is strictly correct.



Cheers,
Phil


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

Re: Problem with Date Command

[Andreas Schwab]

"Dameon G. Rogers" <[EMAIL PROTECTED]> writes:

> Bug-coreutils,
>
>I would like to report a problem with the *date* command:
>
> date +%C
>
> does not function properly.  It says it displays the current century
> but the/ definition /of century means that we are in the 21st not the
> 20th.

The ducumentation is pretty clear on the meaning:

  `%C'
   century.  This is like `%Y', except the last two digits are
   omitted.  For example, it is `20' if `%Y' is `2000', and is `-0'
   if `%Y' is `-001'.  It is normally at least two characters, but it
   may be more.

Andreas.

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


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

Re: Problem with Date Command

[Jim Meyering]

Eric Blake <[EMAIL PROTECTED]> wrote:
> [off-list, since the bulk of the patch is email addresses ;)]
>
> According to Philip Rowlands on 6/5/2008 7:15 AM:
> |> Either the command needs to be changed or the man page needs to be
> |> changed to express what the command actually does.  Any assistance
> |> would be appreciated.
> |
> | I agree that until 2100, it would be better if the manpage gave "20" as
> | the example, or no example at all, but the wording is strictly correct.
>
> Jim, how about the following?

That's a definite improvement.  Pushed.
Thanks!

> Subject: [PATCH] improve 'date +%C' documentation
>
> * src/date.c (usage): Use 20, not 21, for current century.
> * THANKS: Update.
> Reported by Dameon G. Rogers, fix suggested by Philip Rowlands.
> ---
>  THANKS |2 ++
>  src/date.c |2 +-
>  2 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/THANKS b/THANKS
> index feaf463..cb9b098 100644
> --- a/THANKS
> +++ b/THANKS
> @@ -110,6 +110,7 @@ Cray-Cyber Project  
> http://www.cray-cyber.org
>  Cristian Cadar  [EMAIL PROTECTED]
>  Cyril Bouthors  [EMAIL PROTECTED]
>  Dale Scheetz[EMAIL PROTECTED]
> +Dameon G. Rogers[EMAIL PROTECTED]
>  Dan Hagerty [EMAIL PROTECTED]
>  Dan Jacobsonhttp://www.geocities.com/jidani
>  Dan Pascu   [EMAIL PROTECTED]
> @@ -434,6 +435,7 @@ Peter Seebach   [EMAIL PROTECTED]
>  Petter Reinholdtsen [EMAIL PROTECTED]
>  Phelippe Neveu  [EMAIL PROTECTED]
>  Phil Richards   [EMAIL PROTECTED]
> +Philip Rowlands [EMAIL PROTECTED]
>  Philippe De Muyter  [EMAIL PROTECTED]
>  Philippe Schnoebelen[EMAIL PROTECTED]
>  Phillip Jones   [EMAIL PROTECTED]
> diff --git a/src/date.c b/src/date.c
> index 86b3225..aa4d69d 100644
> --- a/src/date.c
> +++ b/src/date.c
> @@ -166,7 +166,7 @@ specifies Coordinated Universal Time.  Interpreted 
> sequences are:\n\
>%c   locale's date and time (e.g., Thu Mar  3 23:05:25 2005)\n\
>  "), stdout);
>fputs (_("\
> -  %C   century; like %Y, except omit last two digits (e.g., 21)\n\
> +  %C   century; like %Y, except omit last two digits (e.g., 20)\n\
>%d   day of month (e.g, 01)\n\
>%D   date; same as %m/%d/%y\n\
>%e   day of month, space padded; same as %_d\n\


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

Request for improving 'date' command

[Ghassem Tofighi]

Hi
I'm a Persian Linux user. I saw in date manual that you are the
developer of date.
As you know there are some other calendars in the world that are used vastly.
In Iran and some another country we use jalali calendar, in Israel
people use jewish calendar and in Arabic country people use hijri
calendar.

I want from you to add some options to the date command that we can
use them in our commands.
for example :

date -j for jalali date
and
date -h for hijri date

I attached two basic codes for jalali and hijri calendar, and you can
use them for that purpose.
Thanks

-- 
--
Ghassem Tofighi
http://ght.ir
I'm available with my Email...Trust me !
[EMAIL PROTECTED]
Don't break Hearts, Please !
---
--


hdate.c
Description: Binary data


jdate.c
Description: Binary data
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Man page ommission, "date" command

[Pierson, Doug (ITD)]

Hello,

 

The "-d STRING" option lacks specification of the valid values for
STRING.  For example, "-d yesterday" is a valid date, but it's not
mentioned in the man page.  

 

Server:

1.  "cat /etc/redhat-release" returns "Red Hat Enterprise Linux AS
release 4 (Nahant Update 5)"
2.  "uname -a" returns "Linux work 2.6.9-42.ELsmp #1 SMP Wed Jul 12
23:27:17 EDT 2006 i686 i686 i386 GNU/Linux"

 

 

Thanks,

Doug Pierson

 

 

 

 

Douglas Pierson

Commonwealth of Massachusetts

Information Technology Division

One Ashburton Place

Room 1601

Boston, MA 02108

 

 

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

Re: Bug in date command

[Eric Blake]

Bob Kline  rksystems.com> writes:

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

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

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

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

Perhaps you wanted the more traditional week number:

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

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

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

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

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

-- 
Eric Blake




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

Re: Bug in date command

[Bob Proulx]

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

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

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

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

The GNU Coreutils date %V documentation says:

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

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

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

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

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

Bob


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

Re: Bug in date command

[Bob Proulx]

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

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

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

How does that look?

Bob


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

Re: Bug in date command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

A couple of nits:

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

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

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

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

iEYEARECAAYFAkllaeEACgkQ84KuGfSFAYBYkwCgmFdOrkSBFAbXtEBrTDe0WDCO
DJ8Ani9RwIt1Cb6vP1cBoF289isk0Hdr
=gJI1
-END PGP SIGNATURE-


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

Re: Bug in date command

[Bob Proulx]

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

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

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

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

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

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

Bob


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

Timezone handling in date command

[Burba, Viktor]

Dear guys,
 
I have expierenced the following unexpeted behaviour by using the "date"
command on SuSE SLES10(x86_64):
 
I have timezone setup to Asia/Dubai (GMT+4), which has short name GST
(Gulf Standart time) 
 
#date
Thu Feb 20 20:00:00 GST 2009
#date --utc -d "now"
Thu Feb 20 16:00:00 UTC 2009  - OK  UTC+4
#date --utc -d "Thu Feb 20 20:00:00 GST 2009"
Thu Feb 20 10:00:00 UTC 2009  - ???  UTC+10
 
I think here some name problems with GST. Because there are four
timezones with the same short name GST
 
Guam Standart Time UTC+10
Gulf Standart Time UTC+4
Greenland Standart Time UTC-3
South Georgia Time UTC-2
 
Here looks like date uses UTC+10 for name GST, which is also timezone
GST but Guam Standart time and not Gulf Standart time.
How can I force date to use another time offset for GST name?
 
 
Best regards,
Viktor Burba
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: bug in date-command

[Bob Proulx]

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

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

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

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

Try these:

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

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

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

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

And the documentation here:

  info coreutils "General date syntax"

Bob


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

Re: bug in date-command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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

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

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

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

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


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

BUGs in de date command

[Patricio Baya]

hello

I have a problem with the DATE command.

when a put the command:  
[EMAIL PROTECTED] controles]$ date
vie oct 31 13:41:49 ART 2003
[EMAIL PROTECTED] controles]$ date -d "1 month ago"
mié oct  1 13:42:04 ART 2003

The re is a big mistake. If today is 31/10/2003 , 1 Month Ago must return or 30/09 or someting else, but not  "OCT 1"


thanx

bye



-- 
Patricio Baya <[EMAIL PROTECTED]>
AFIP






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

Re: bug in date command

[Andreas Schwab]

"duncan brown" <[EMAIL PROTECTED]> writes:

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

  %C   century (year divided by 100 and truncated to an integer) [00-99]

Andreas.

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


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

Re: bug in date command

[Bauke Jan Douma]

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

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

BJ


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

Re: bug in date command

[Andreas Schwab]

Bauke Jan Douma <[EMAIL PROTECTED]> writes:

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

Why?

$ date +%C%y
2004

Andreas.

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


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

Re: bug in date command

[Bauke Jan Douma]

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

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

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

BJ


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

Re: bug in date command

[Andreas Schwab]

Bauke Jan Douma <[EMAIL PROTECTED]> writes:

> On Fri, May 14, 2004 at 11:27:53AM +0200, Andreas Schwab wrote:
>> Bauke Jan Douma <[EMAIL PROTECTED]> writes:
>> 
>> > On Fri, May 14, 2004 at 12:51:20AM +0200, Andreas Schwab wrote:
>> >> "duncan brown" <[EMAIL PROTECTED]> writes:
>> >> 
>> >> > date +%C reports the 20th century, but we've been in the 21st since jan 01, 
>> >> > 00:00:00
>> >> 
>> >>   %C   century (year divided by 100 and truncated to an integer) [00-99]
>> >
>> > Surely this must be a Y2K-ism in the standard, no?
>> 
>> Why?
>> 
>> $ date +%C%y
>> 2004
>
> I am sorry, I answered under the assumption that you wrote
> 'truncated to the closest integer'.
>
> Still, there is discrepancy in one common meaning of the word
> 'century' and the meaning it has here, as the original
> poster noted.  Here it apparently means something like 'the
> century part of the full year-number.'

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

Andreas.

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


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

Re: problems with date command

[Paul Eggert]

Alaw Guo <[EMAIL PROTECTED]> writes:

> When I give the command:
>
>   date --date="1/1/1970 00:00:`date +"%s"`"
>
> Shouldn't this give me the current time?

The +%s format counts UTC seconds, but you are asking "date" to print
local times.  This may help to explain the other results that you got.

> instead, on a RedHat 9 and a Fedora Core 1 system I get:
>
>   [EMAIL PROTECTED] bin]# date ; date --date="1/1/1970 00:00:`date +"%s"`"
>   Sun Jul 25 12:49:32 PDT 2004
>   Sun Jul 25 20:49:32 PDT 2004

Yes, that looks right for Pacific time (8 hours behind UTC on
1970-01-01).  Although I should mention that that particular syntax
isn't documented and so it isn't really supported

> and on a Fedora Core 2 system I get:
>
>   [EMAIL PROTECTED] cgi-bin]# date ; date --date="1/1/1970 00:00:`date +"%s"`"
>   Sun Jul 25 12:50:44 PDT 2004
>   Thu Jan  1 00:00:59 PST 1970

I can't reproduce this behavior on my host (Debian GNU/Linux 3.0r1,
coreutils 5.2.1, TZ=America/Los_Angeles).


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

Re: problems with date command

[Paul Jarc]

Paul Eggert <[EMAIL PROTECTED]> wrote:
> Alaw Guo <[EMAIL PROTECTED]> writes:
>>   [EMAIL PROTECTED] cgi-bin]# date ; date --date="1/1/1970 00:00:`date +"%s"`"
>>   Sun Jul 25 12:50:44 PDT 2004
>>   Thu Jan  1 00:00:59 PST 1970
>
> I can't reproduce this behavior on my host (Debian GNU/Linux 3.0r1,
> coreutils 5.2.1, TZ=America/Los_Angeles).

It happens for me.  TZ=America/Los_Angeles or right/US/Eastern,
coreutils 5.2.1, gcc 3.2.3 or 3.3.3, glibc 2.3.2, all built from
source.


paul


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

bug found on date command

[soner . balkir]

  Hi,
  There is a serious bug on date command. when i type " date +%C " i get the
outout " 20 " instead of " 21 " . I hope you fix this bug soon. There may be
some Linux users thinking that they are living at the 20th century :)
Thanks...
 


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

Re: bug in date command

[Pádraig Brady]

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

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

> In addition, is there any option to have lowercase ?

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

cheers,
Pádraig.

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

Re: error in date command

[Brian Dessent]

Adam Miller wrote:

>According to the man page, /bin/date +%x should report the
> date in the following format: mm/dd/yy

No it doesn't, it says it reports the date in the format appropriate to
the current locale:

   %x locale's date representation (e.g., 12/31/99)

Note that "e.g." means it's an example of one possible format.

>However, when run in bash the command above reports the date in the
> following format: mm/dd/

Compare the output of:

LANG=C /bin/date +%x

to

LANG=en_US /bin/date +%x

>I have been calling a bash script in through cron, which reports the
> date as it should.  So why would running the command in bash be different?

You most likely have something in your rc/profile scripts which only
runs for interactive login shells that sets the locale (LC_* and/or LANG
environment variables.)  When run from the cron job they are not set and
the default "C" locale is used.

Brian


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

Re: error in date command

[Eric Blake]

>According to the man page, /bin/date +%x should report the 
> date in the following format: mm/dd/yy

Thanks for the report.  However, according to the man page of
the latest stable version of coreutils, 5.94, %x gives the
"locale's date representation (e.g., 12/31/99)".  You may also
be interested in the man page for strftime.  In short, if your
locale is not set to C or POSIX, then %x might produce
something other than mm/dd/yy, because that is what it
was designed to do.  Also, your version of coreutils is a
couple of years out of date, you may be interested in upgrading.

> 
>However, when run in bash the command above reports the date in the 
> following format: mm/dd/

Try rerunning as:
env LC_ALL=C /bin/date +%x

-- 
Eric Blake


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

bug#17451: date command: Bug?

[Yin, Dazhong@ARB]

When querying the time zone, the date command cannot deal with the hour when 
time changes from standard time to daylight saving time.  Below examples show 
the tests done in the Pacific time zone.

---

date -d "20120311 01" +%:::z
-08

date -d "20120311 02" +%:::z
date: invalid date `20120311 02'

date -d "20120311 03" +%:::z
-07

date -d "20140309 01" +%:::z
-08

date -d "20140309 02" +%:::z
date: invalid date `20140309 02'

date -d "20140309 03" +%:::z
-07

bug#17451: date command: Bug?

[Eric Blake]

tag 17451 notabug
thanks

On 05/09/2014 12:07 PM, Yin, Dazhong@ARB wrote:
> When querying the time zone, the date command cannot deal with the hour when 
> time changes from standard time to daylight saving time.

That's because that hour does not exist in your timezone.

All of your examples look like correct behavior to me.  You've asked a FAQ:
https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e

Our advice is to compute dates in UTC, or when sticking to a locale with
daylight savings, then compute dates relative to noon rather than near
the hour that might disappear or be doubled.

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



signature.asc
Description: OpenPGP digital signature

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

[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

Re: Request for improving 'date' command

[Paul Eggert]

Thanks for those contributions, but my understanding is that the
Persian calendar is astronomical, which means any numeric calculation
would be an approximation, right?  What approximation is being used
here?  Does the code work for dates arbitrarily in the past or future,
when time_t is 64 bits for example?  (I suspect the answer is "no".)
That sort of thing.

For more on this subject, please see Reingold & Dershowitz's excellent
book "Calendrical Calculations", 3rd
ed. .
It mentions multiple ways to approximate the Persian calendar, among
other things.

I suspect that modifying "date" to support the Persian calendar (much
less Hebrew, Hindu, Islamic, etc.) would be nontrivial, and would be
best done in a library that could be used by many programs, not just
"date".  You might want to look at Emacs's calendar code for ideas for
such a project, as the Emacs code was written by Reingold a while back
and is high quality.  (It's in Lisp, though.)


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

Re: Man page ommission, "date" command

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Pierson, Doug (ITD) on 10/21/2008 11:30 AM:
> 
> The "-d STRING" option lacks specification of the valid values for
> STRING.  For example, "-d yesterday" is a valid date, but it's not
> mentioned in the man page.  

Thanks for the report.  However, the man page is generated from the --help
output, which is already quite lengthy.  It also includes this sentence:

  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 date

  should give you access to the complete manual.

Furthermore, within the info manual, the documentation of valid date
formats spans several pages (ie. it is WAY too complex to concisely
summarize in one or two sentences).

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

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

iEYEARECAAYFAkj+JkEACgkQ84KuGfSFAYCgIACeKpb7U/xK8ymv4R9iMW6yHnJg
tmUAn25p/U441X5+EEbiD5QAMc3K9OjG
=ZXCL
-END PGP SIGNATURE-


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

Re: Timezone handling in date command

[James Youngman]

On Thu, Feb 19, 2009 at 12:11 PM, Burba, Viktor
 wrote:
> Dear guys,
>
> I have expierenced the following unexpeted behaviour by using the "date"
> command on SuSE SLES10(x86_64):
>
> I have timezone setup to Asia/Dubai (GMT+4), which has short name GST
> (Gulf Standart time)
>
> #date
> Thu Feb 20 20:00:00 GST 2009
> #date --utc -d "now"
> Thu Feb 20 16:00:00 UTC 2009  - OK  UTC+4
> #date --utc -d "Thu Feb 20 20:00:00 GST 2009"
> Thu Feb 20 10:00:00 UTC 2009  - ???  UTC+10
>
> I think here some name problems with GST. Because there are four
> timezones with the same short name GST
>
> Guam Standart Time UTC+10
> Gulf Standart Time UTC+4
> Greenland Standart Time UTC-3
> South Georgia Time UTC-2
>
> Here looks like date uses UTC+10 for name GST, which is also timezone
> GST but Guam Standart time and not Gulf Standart time.
> How can I force date to use another time offset for GST name?

It is probably better to use TZ=Asia/Dubai.   See
$ info coreutils "Specifying time zone rules"

James.


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

Possible improvement of the date command

[Alexander Veit]

Dear coreutils maintainers,

to facilitate date calculations I would suggest format specifiers to output
the date as a julian date with and without day fraction, e.g.

# date --date='2003-09-10' +%u
2452893

# date --date='2003-09-10 18:00:00' +%U
2452893.25

Implementations may use the Jean Meeus or the Fliegel-Van Flandern
algorithm.


Best regards,
Alexander Veit

--
mailto:[EMAIL PROTECTED]



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

Re: BUGs in de date command

[Paul Eggert]

Patricio Baya <[EMAIL PROTECTED]> writes:

> [EMAIL PROTECTED] controles]$ date
> vie oct 31 13:41:49 ART 2003
> [EMAIL PROTECTED] controles]$ date -d "1 month ago"
> mià oct 1 13:42:04 ART 2003
> The re is a big mistake. If today is 31/10/2003 , 1 Month Ago must return or
> 30/09 or someting else, but not "OCT 1"

I don't see why it's a big mistake.  1 month before October 31 is
"September 31".  But there is no "September 31", so you've specified
an ambiguous day.  September 30 and October 1 are both reasonable ways
to resolve the ambiguity.

It might be nice to change "date" to behave the way that you like, but
I don't see why the current behavior is a bug.


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

Re: bug found on date command

[Bob Proulx]

[EMAIL PROTECTED] wrote:
>   There is a serious bug on date command. when i type " date +%C " i get the
> outout " 20 " instead of " 21 " . I hope you fix this bug soon. There may be
> some Linux users thinking that they are living at the 20th century :)

Here is what the standards documents say about it.

  Century (a year divided by 100 and truncated to an integer) as a
  decimal number [00-99].

The algorithm is explicit that %C is the two digit century part of the
current year.  This is not the same as the 20th or 21st century
definition.  It is instead used to slice up the date into component
parts.

For example, this should return the current year.

  date +%C%y
  2004

Bob


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

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

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

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