Re: date command

2010-03-05 Thread 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.
> 





Re: date command

2010-03-05 Thread 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

2010-02-15 Thread 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

2008-05-31 Thread 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

2008-02-28 Thread 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

2008-02-01 Thread 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

2008-02-01 Thread 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

2008-02-01 Thread 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

2008-02-01 Thread 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

2008-02-01 Thread 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 .
> 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