-05-04', I get the result as below.
>
> Maybe it is a bug of Date command , Please help to find it, Thanks.
Thanks for the report. However, it is most likely the only bug here is
your understanding of how date operates around daylight savings events:
http://www.gnu.org/software/core
Dear David,
When I input the comman 'date "+%Y%m%d" -d "1986-05-04 1 day"' to get the
next day of '1986-05-04', I get the result as below.
Maybe it is a bug of Date command , Please help to find it, Thanks.
Regards,
Lijian 65631
Email: <
>> 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 e
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 fro
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
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 s
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 ru
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 1/1/2010 8:12 AM:
> According to Gary Warner on 1/1/2010 8:09 AM:
>> NOWDATE=`date +%g%b%d`
>
> Not a bug.
> http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-workin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Gary Warner on 1/1/2010 8:09 AM:
> NOWDATE=`date +%g%b%d`
Not a bug.
http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#The-date-command-is-not-working-right_002e
- --
Don't work too hard, make some time for fun as wel
I'm having an issue with the spam data mine that seems to be related to the
linux "date" command.
This morning's spam is being labeled as being from 2009. I immediately assumed
that someone had hardcoded a year, and started examining code to see who I
should scold abou
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
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
Update of bug #25406 (project coreutils):
Assigned to:None => meyering
Open/Closed:Open => Closed
___
Follow-up Comment #2:
Fixed in release
-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 d
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 (strange
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 (strange
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 Sta
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
Follow-up Comment #1, bug #25406 (project coreutils):
That looks like a bug alright, or at least an error in the docs.
It was mentioned before actually:
http://lists.gnu.org/archive/html/bug-coreutils/2007-09/msg00132.html
___
Reply to t
URL:
<http://savannah.gnu.org/bugs/?25406>
Summary: date command, using --date option, only sees out 6
days.
Project: GNU Core Utilities
Submitted by: tombro
Submitted on: Sun 25 Jan 2009 04:46:47 PM GMT
Category
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 IS
-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 -
rg/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
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
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
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...@rksystem
-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.
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. "una
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 fo
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.
T
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
"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 mean
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
-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'
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
[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 t
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 altern
On Wed, 9 Apr 2008, Chinnakka K Batakurki wrote:
When I changed the Linux system time by using date -s command,
the info is not logged to /var/log/wtmp
wtmp is a file for recording user login/logout activity.
whereas when I change the Hardware clock with hwclock command, it is
logged to : /
Hi,
When I changed the Linux system time by using date -s command, the
info is not logged to /var/log/wtmp
whereas when I change the Hardware clock with hwclock command, it is logged
to : /etc/adjtime
Could you please let me know is there any setting needs to be done to get
the logs related to
[ 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 ab
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
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 comma
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 comma
; > 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
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'
t; <[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 MES
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
-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/
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
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 r
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
-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
-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
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.gn
>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 inter
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." me
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 shoul
[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 :)
H
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...
_
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,
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.
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:
[
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
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
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
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 mu
"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, 90
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-coreuti
Thanks for the patches to coreutils-5.1.2 to fix the problem with the
zero nanosec values in output from stat. They work nicely:
Old:
% /usr/local/bin/stat --version
stat (coreutils) 5.1.2
% /usr/local/bin/stat /bin/true
File: `/bin/true'
Size: 312
"Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
> Also, it would be helpful if GNU date (also part of coreutils) could
> input and output time values since the epoch given on the command
> line, since that would make time conversions easy. I know there is a
> perl module to do that, and GNU gawk c
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
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 m
"Alexander Veit" <[EMAIL PROTECTED]> writes:
> 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
Only if you're 12 or more hours ahead of UTC; otherwise the correct
answer is 2452892. Or did y
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
101 - 174 of 174 matches
Mail list logo
