d0ct0r wrote:
Today, I did the check the settings for my BC637 card. I was surprised
that its overwrite my manual setting for the Leap Event by following
information:
Time Settings:
Mode : GPS
Time Format: Binary
Year
The referenced article indicates that they apply the smear to their NTP
servers and allow
the clients to track the servers. This approach would place some limits
on the minimum
lead time you would need to implement the smear.
1) you would have to start early enough for the servers to detect
I've often wondered why more systems don't use TAI or other similar time scales
as their time source. If needed the time displayed to end users or third
parties could be converted to UTC just prior to presentation or transmittal.
For example a financial system that needs to time stamp
martin.burni...@burnicki.net said:
So I think they smeared it over more than just a few minutes. I'd expect
some hours, so standard NTP clients would just notify this as clock drift
(oscillator frequency offset) which they'd have to compensate. Since ntpd's
control loop is pretty slow it
Hi Tom,
You are correct, but it does not really matter because it will not be
instantaneous, and for a period of time that is well within the range of human
perception, the clock will be off by more than you would normally expect.
We have been talking about NTP being able to keep the time to
Today, I did the check the settings for my BC637 card. I was surprised
that its overwrite my manual setting for the Leap Event by following
information:
Time Settings:
Mode : GPS
Time Format: Binary
Year : 1995
I haven't looked at the raw data, but using the windows apps:
a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not.
lady heather is not
Interesting. I don't see any leap-pending from a Z3801A. (or a KS-24361)
Hi Hal,
It's not that simple. There are many different
Keep in mind that this system drives you to having pretty bad time for the
better part of a whole day, on purpose... I realize that when the
Hi Didier,
The google article never claims the smear spans an entire day. I think you may
be confusing references to the leap smear with a DIY digital
michael.c...@sfr.fr said:
I havenât looked at the raw data, but using the windows apps:
a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not.
lady heather is not
Interesting. I don't see any leap-pending from a Z3801A. (or a KS-24361)
There is another interesting
There are many systems for which the Google fix would not work in the
current state of technology unless implemented by EVERYBODY synchronously.
At least everybody who depends on precise time like banking and financial
systems, let alone the physicists and many others...
Keep in mind that this
Hi
If section 4 is going to turn in to a list of suspects to investigate and
tabulate, I would add:
4 e) CDMA runs on GPS (not UTC) time. A “pure CDMA” GPSDO may be coded to
ignore leap second data altogether. The ones I’m thinking about are the GPSTM
boxes that put out very CDMA specific
I don't know for sure which category the Ball/Efratom MGPS
(as found in the MFS-XXX Modular Frequency Standard frames) is
in yet But the MGPS has a screen labeled Current Leap Second,
that according to the manual:
The display indicates the date and time of the current leap second.
Leap
Tom Van Baak wrote:
I haven't looked at the raw data, but using the windows apps:
a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not.
lady heather is not
Interesting. I don't see any leap-pending from a Z3801A. (or a KS-24361)
Hi Hal,
It's not that simple. There
Tom Van Baak wrote:
Keep in mind that this system drives you to having pretty bad time for the
better part of a whole day, on purpose... I realize that when the
Hi Didier,
The google article never claims the smear spans an entire day. I
think you may be confusing references to the leap smear
On 1/9/15 4:57 PM, Henry Hallam wrote:
Such slewing solutions are OK for Google. They wouldn't work well for
one of the systems I work with, which uses system time to calculate
the position of a LEO satellite for purpose of pointing a 7.6 meter
X-band dish. Half a second of error corresponds
On 1/10/15 1:25 PM, Hal Murray wrote:
jim...@earthlink.net said:
Which is why we use TAI in the space business and don't fool with this
Greenwich Mean Time or Coordinated Universal Time which is
discontinuous and potentially non-monotonic.
Does the system clock on your PCs run on TAI or do
jim...@earthlink.net said:
Which is why we use TAI in the space business and don't fool with this
Greenwich Mean Time or Coordinated Universal Time which is
discontinuous and potentially non-monotonic.
Does the system clock on your PCs run on TAI or do they have a separate clock
for space
Such slewing solutions are OK for Google. They wouldn't work well for
one of the systems I work with, which uses system time to calculate
the position of a LEO satellite for purpose of pointing a 7.6 meter
X-band dish. Half a second of error corresponds to a pointing error
of 0.5 degrees, well
t...@patoka.org said:
1s/24h = 1/86400 which is approximately 12ppm. That means that Aging Offset
could slow down my clock for 1 second if I'll apply the maximum value one
day ahead (roughly). I need to do some experiments first. ;-) Its looks too
unreliable for me.
If you do it that
Tom Van Baak wrote:
I couldn't help noticing that Debian just issued an update
to tzone, so that means Linux systems now know about the
leap second.
-Chuck Harris
Hi Chuck,
Linux systems now know about the leap second -- this is a very
dangerous assumption. And one reason why leap seconds
Reading about leap seconds for the past two days, I found that common
solution for it - just encode leap second event proactively and wait
for it.
Of course that possible only if device has that option. For example,
BC637PCI has a menu item 7. Program Leap Event Seconds. Which I did.
Now,
On Fri, Jan 9, 2015 at 3:21 PM, Martin Burnicki
martin.burni...@burnicki.net wrote:
Systems which are simply time clients can receive the leap second warning
via the usual protocols like NTP or PTP/IEEE1588.
Indeed, they can. Even when there hasn't been a leap-second.
Practically all internet
This is an issue indeed. Here is what I get from MySQL Data Base support
site:
Before MySQL 5.0.74, if the operating system is configured to return
leap seconds from OS time calls or if the MySQL server uses a time zone
definition that has leap seconds, functions such as NOW() could return
d0ct0r wrote:
Reading about leap seconds for the past two days, I found that common
solution for it - just encode leap second event proactively and wait
for it.
Of course that possible only if device has that option. For example,
BC637PCI has a menu item 7. Program Leap Event Seconds. Which I
Gregory Maxwell wrote:
On Fri, Jan 9, 2015 at 3:21 PM, Martin Burnicki
martin.burni...@burnicki.net wrote:
Systems which are simply time clients can receive the leap second warning
via the usual protocols like NTP or PTP/IEEE1588.
Indeed, they can. Even when there hasn't been a leap-second.
Correct me if I'm wrong, but as I understand it the tzfile in the
tzone package is not used to update the system time - that relies on
NTP or similar. Rather, the leap second info in the tzone files is
made available for applications to use, primarily for calculating time
differences in the past.
I couldn't help noticing that Debian just issued an update
to tzone, so that means Linux systems now know about the
leap second.
-Chuck Harris
Hi Chuck,
Linux systems now know about the leap second -- this is a very dangerous
assumption. And one reason why leap seconds have gotten out of
I couldn't help noticing that Debian just issued an update
to tzone, so that means Linux systems now know about the
leap second.
-Chuck Harris
Tim Shoppa wrote:
I'm not sure there's any computer time package that correctly disambiguates
23:59:59 vs 23:59:60 in UTC timestamps in a general
in advance. When either of the two flags is set, the kernel will trigger
the leap event in the last seconds of the current day. GPS should announce
the pending leap second not long after the IERS announcement. I haven't
checked my clocks yet but it may already be out there.
I haven’t looked
t...@patoka.org said:
The question is how usually GPS modules handle leap seconds ? Is it
satelates who send UTC time to GPS module or GPS module has firmware with
leap second information hard-coded ?
The satellites send GPS time with a low bandwidth footnote that provides the
offset to UTC
The difference between GPS time and UTC (due to leap seconds) is
broadcast in the GPS navigation message[1] so all but the most poorly
designed GPS modules should take care of it and output the correct UTC time.
Henry,
This is not quite true. First, page 18 of subframe 4 is only broadcast
The difference between GPS time and UTC (due to leap seconds) is
broadcast in the GPS navigation message[1] so all but the most poorly
designed GPS modules should take care of it and output the correct UTC
time.
I'm not going to get into the mess of unix epoch time. Basically,
it's not a
Tom,
Thanks for the comments ! In my design I am using NMEA as an option to
set initial time on the clock. Its just faster and more convenient than
doing it manually. And in the other (rare) occasions when clock logic
could decide to sync. RTC module time with time received from GPS
module.
Tim,
I was using perl as a tool to calculate UNIX time. As my project based
on STM32 MCU, I have no option to use time libraries. And I dont' think
its applcable for my project. I am thinking what exactly of that UNIX
time is. Looks like its using simple constants, like we have 86400
I think you can see this as a 15 second jump if you watch
a GPS receiver doing a cold start. I mean really cold as in
no memory at all rather than it
t...@patoka.org said:
Exactly ! I saw that behaviour few times.But I was thinking its because of
some very old satelites which knows
I'm not sure there's any computer time package that correctly disambiguates
23:59:59 vs 23:59:60 in UTC timestamps in a general purpose way. Some
software simply rejects 23:59:60 UTC as invalid, some will quietly map it
to 23:59:59 effectively making those two seconds impossible to distinguish.
Hello,
As I am in the process of creation of my own Nixie clocks. And it
probably good time frame to clarify one thing about leap seconds. In my
project I am using GPS module as an option to have current UTC time and
also to have 1PPS signal to do auto-adjustment for external RTC module.
software is incapable of displaying or parsing the
23:59:60 leap second correctly.
/tvb
- Original Message -
From: d0ct0r t...@patoka.org
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Tuesday, January 06, 2015 1:01 PM
Subject: Re: [time-nuts] June 30
On 7 Jan 2015 00:23, d0ct0r t...@patoka.org wrote:
Hello,
The same question is for UNIX epoch time. How computers knows if it is
necessary to add leap seconds ?
During the event, the kernel raw time (assuming UTC) will go from
23:59:58.9 straight to 00:00:00.0 when removing
Just announced: there will be a positive leap second at the end of June 30 2015
UTC (that's Wednesday July 1st for most of the world).
As usual we time nuts will have a leap second party -- where we capture and
share the magic hh:59:60 display on as many different clocks and instruments as
40 matches
Mail list logo
