Re: date command
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
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
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
[ 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
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
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
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
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
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
