On Mon 2019-01-21T15:32:27-0800 Paul Hirose hath writ:
> On 2019-01-16 1:35, Steve Allen wrote:
> > So starting 1970-01-01 DCF77 changed to broadcast Stepped Atomic Time
> > (SAT) with second markers that were 1 SI second apart except on
> > occasions when they were 1.2 SI seconds apart in order
On 2019-01-16 1:35, Steve Allen wrote:
So starting 1970-01-01 DCF77 changed to broadcast Stepped Atomic Time
(SAT) with second markers that were 1 SI second apart except on
occasions when they were 1.2 SI seconds apart in order that the time
markers would stay close to UT2.
For fun (?) I wrote
On 2019-01-18 17:11, Michael H Deckers wrote:
.. insert a step of 0.2 s in their time signal about every 71 days.
when he meant "about every 77 days".
Michael Deckers.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
On Wed 2019-01-16T22:24:46-0800 Paul Hirose hath writ:
> On 2019-01-16 1:35, Steve Allen wrote:
> >
> > Does it know that rubber seconds do not apply to timestamps in central
> > Europe made using DCF77 from 1970-01-01 to 1972-01-01?
>
> All my DLL knows is what's in the UTC file. If the file
On 2019-01-16 1:35, Steve Allen wrote:
Does it know that rubber seconds do not apply to timestamps in central
Europe made using DCF77 from 1970-01-01 to 1972-01-01?
All my DLL knows is what's in the UTC file. If the file indicates no
rate offset in the years 1970-71 and some fractional
On 1/16/19 12:31 AM, Poul-Henning Kamp wrote:
In message <20190115205243.gb25...@ucolick.org>, Steve Allen writes:
On Tue 2019-01-15T12:34:11-0800 Gary E. Miller hath writ:
Yes, and no. time_t is just seconds since an epoch. Which epoch
is not well defined. The epoch may well be
On 1/15/19 11:36 PM, Warner Losh wrote:
> It's a fundamental flaw of UTC. There are other ways to implement
> something akin to UTC that implements some form of mean solar time
> that's not an observational calendar.
If either part of this is consensus, then a proposal to redefine UTC
after a
On Wed 2019-01-16T00:00:55-0800 Paul Hirose hath writ:
> The "rubber second" era is supported. That accounted for about 90% of the
> workload to create the UTC implementation!
Does it know that rubber seconds do not apply to timestamps in central
Europe made using DCF77 from 1970-01-01 to
On Wed 2019-01-16T09:03:26+ Poul-Henning Kamp hath writ:
> In message <20190116085619.ga23...@ucolick.org>, Steve Allen writes:
> >The epoch of TAI, and LORAN, and GPS is 1961-01-01T20:00:00 UT2.
> >Or maybe 1961-01-00 UT2.
> >
> >That is when the atomic time scale was set to a specified
In message <20190116085619.ga23...@ucolick.org>, Steve Allen writes:
>On Wed 2019-01-16T08:31:19+ Poul-Henning Kamp hath writ:
>> In message <20190115205243.gb25...@ucolick.org>, Steve Allen writes:
>> >That evokes a challenge for all time nuts that I can make based on
>> >reading
On Wed 2019-01-16T08:31:19+ Poul-Henning Kamp hath writ:
> In message <20190115205243.gb25...@ucolick.org>, Steve Allen writes:
> >That evokes a challenge for all time nuts that I can make based on
> >reading Bulletin Horaire.
> >
> >What is the epoch that was used for TAI?
>
> Isn't that the
In message <20190115205243.gb25...@ucolick.org>, Steve Allen writes:
>On Tue 2019-01-15T12:34:11-0800 Gary E. Miller hath writ:
>> Yes, and no. time_t is just seconds since an epoch. Which epoch
>> is not well defined. The epoch may well be anything. See "man difftime".
>
>That evokes
In message <20190115123411.44a0c...@spidey.rellim.com>, "Gary E. Miller" writes
:
>> But the underlying time_t cannot represent leap seconds, can it?
>
>Yes, and no. time_t is just seconds since an epoch. Which epoch
>is not well defined. The epoch may well be anything. See "man
On 2019-01-15 10:50, Tom Van Baak wrote:
For instance, in Python, if I do a datetime(2016,12,31,0,0,0) +
timedelta(hours=30) does it come out as 1/1/2017 6:00:00 or 5:59:59 (it
comes out 0600)
Here's a C# code fragment which performs a similar computation. To make
the demonstration more
On Tue, Jan 15, 2019 at 10:09 PM Gary E. Miller wrote:
> Yo Warner!
>
> On Tue, 15 Jan 2019 17:45:32 -0700
> Warner Losh wrote:
>
> > > > Except that's not a leap second. struct tm doesn't do leap seconds
> > > > really. It kinda sorta does, but it kinda sorts doesn't.
> > >
> > > Well, it does
On 1/15/19 9:14 PM, jimlux wrote:
> Ground processing only - for user convenience
I see somebody else mentioned SPICE, which I assumed you knew all about.
>>
>> Or more simply, how accurate are the satellite's GPS week and
>> millisecond values?
>
> Time is set by the messages from the OEM-6xx
Yo Warner!
On Tue, 15 Jan 2019 17:45:32 -0700
Warner Losh wrote:
> > > Except that's not a leap second. struct tm doesn't do leap seconds
> > > really. It kinda sorta does, but it kinda sorts doesn't.
> >
> > Well, it does in a modern Linux kernel. Otherwise NTPD would fail
> > on the leap
JPL has a nice library for computing spacecraft location and
pointing, SPICE ,
with interfaces in Fortran, C, IDL, Matlab, while others have
created interfaces in other languages. Relevant here is the
extensive well-tested time conversions
.
It's
On Tue 2019-01-15T15:18:00-0800 jimlux hath writ:
> It would be much easier for the operators if they could just *enter* the UTC
> time, and have the software calculate the GPS Week:millisecond (or vice
> versa)
The 1970 CCIR decision to begin having leap seconds was made without
any technical
On 1/15/19 6:34 PM, Rob Seaman wrote:
Hi Jim,
The use case is this - I have a satellite in orbit which does
everything internally in terms of GPS week and millisecond of week.
Folks on the ground work in UTC, since that's what the plethora of PCs
are using.
Just to verify. The satellite does
Hi Jim,
> The use case is this - I have a satellite in orbit which does
> everything internally in terms of GPS week and millisecond of week.
> Folks on the ground work in UTC, since that's what the plethora of PCs
> are using.
>
Just to verify. The satellite does use GPS as its reference clock,
On Tue, Jan 15, 2019 at 1:50 PM Gary E. Miller wrote:
> Yo Warner!
>
> On Tue, 15 Jan 2019 12:43:46 -0700
> Warner Losh wrote:
>
> > Except that's not a leap second. struct tm doesn't do leap seconds
> > really. It kinda sorta does, but it kinda sorts doesn't.
>
> Well, it does in a modern
Yo jimlux!
On Tue, 15 Jan 2019 15:18:00 -0800
jimlux wrote:
> It would be much easier for the operators if they could just *enter*
> the UTC time, and have the software calculate the GPS
> Week:millisecond (or vice versa)
I've been wanting that CLI tool for a while. I'll add it to the gpsd
On 1/15/19 11:41 AM, Rob Seaman wrote:
Isn't this covered (for instance) in section 20.3.3.5.2.4(b) of
IS-GPS-200J (https://www.gps.gov/technical/icwg/IS-GPS-200J.pdf)? The
various libraries and operating systems listed deal with none of the
reference time scales (GPS, UTC, or TAI, for that
On Tue 2019-01-15T10:50:10-0800 Tom Van Baak hath writ:
> Nope. All minutes have 60 seconds in Excel. And in Windows. And
> in Unix/POSIX. Really any computer system that uses a fixed "epoch"
> and a ticking "counter" is ruined by leap seconds. The systems differ
> in their epoch's, they all
On Tue 2019-01-15T13:10:54-0800 Gary E. Miller hath writ:
> > What is the epoch that was used for TAI?
> "TAI in this form was synchronised with Universal Time at the beginning
> of 1958,"
That is conceptually the case, but even as a concept it deserves
explanation about how it was that the USNO
Yo Steve!
On Tue, 15 Jan 2019 12:52:43 -0800
Steve Allen wrote:
> On Tue 2019-01-15T12:34:11-0800 Gary E. Miller hath writ:
> > Yes, and no. time_t is just seconds since an epoch. Which epoch
> > is not well defined. The epoch may well be anything. See "man
> > difftime".
>
> That evokes
On Tue 2019-01-15T12:34:11-0800 Gary E. Miller hath writ:
> Yes, and no. time_t is just seconds since an epoch. Which epoch
> is not well defined. The epoch may well be anything. See "man difftime".
That evokes a challenge for all time nuts that I can make based on
reading Bulletin Horaire.
Yo Warner!
On Tue, 15 Jan 2019 12:43:46 -0700
Warner Losh wrote:
> Except that's not a leap second. struct tm doesn't do leap seconds
> really. It kinda sorta does, but it kinda sorts doesn't.
Well, it does in a modern Linux kernel. Otherwise NTPD would fail
on the leap second, and that only
On Tue 2019-01-15T11:49:00-0800 Tom Van Baak hath writ:
> Still, I bet more astronomers use Python than Excel to point
> telescopes. How do you handle the lack of leap second support in
> Python?
I can't say that anyone uses Python to point a telescope, but it
does not matter if they do. See
Yo Steve!
On Tue, 15 Jan 2019 11:46:02 -0800
Steve Allen wrote:
> I would love to find pointers to such strategies and code.
In the gpsd code look in the file: gpsd/timebase.c
In the NTPsec code look in the files: ntpd/ntp_leapsec.c and ntptime/ntptime.c
RGDS
GARY
Yo Tom!
On Tue, 15 Jan 2019 11:40:07 -0800
"Tom Van Baak" wrote:
> But the underlying time_t cannot represent leap seconds, can it?
Yes, and no. time_t is just seconds since an epoch. Which epoch
is not well defined. The epoch may well be anything. See "man difftime".
time_t dates to the
On Tue 2019-01-15T12:52:18-0700 Warner Losh hath writ:
> This suggests strongly that those models of time are fatally flawed and
> should be revisited.
I am probably the only person who has ever read all of Bulletin Horaire.
https://www.ucolick.org/~sla/leapsecs/bhissues.html
I can say that with
On Tue, Jan 15, 2019 at 12:41 PM Rob Seaman wrote:
> Isn't this covered (for instance) in section 20.3.3.5.2.4(b) of
> IS-GPS-200J (https://www.gps.gov/technical/icwg/IS-GPS-200J.pdf)? The
> various libraries and operating systems listed deal with none of the
> reference time scales (GPS, UTC,
On Tue, Jan 15, 2019 at 11:58 AM Gary E. Miller wrote:
> Yo Tom!
>
> On Tue, 15 Jan 2019 10:50:10 -0800
> "Tom Van Baak" wrote:
>
> > Nope. All minutes have 60 seconds in Excel. And in Windows. And in
> > Unix/POSIX.
>
> Not quite. Check out "man gmtime" for one way that POSIX represents time.
> If you set your POSIX system clock at TAI minus 10 seconds then
> it keeps track of the number of seconds which have been counted
> in the internationally approved radio broadcast time scales.
So, wait. In order to use Python for any proper UTC processing you have to
configure your PC to run
On Tue 2019-01-15T12:41:27-0700 Rob Seaman hath writ:
> The bread-and-butter leap second discussions on this list seem
> irrelevant to simply meeting an engineering requirement to adhere to
> whatever standard. If POSIX, python, excel, whatever don't provide
> canned tools to convert seamlessly
On Tue 2019-01-15T11:40:07-0800 Tom Van Baak hath writ:
> Also, presumably Python is based on POSIX? Does it use time_t or
> gmtime? Why did Jim's quick Python experiment fail?
Guido said that the mainline of Python would not support leap seconds.
--
Steve Allen
Isn't this covered (for instance) in section 20.3.3.5.2.4(b) of
IS-GPS-200J (https://www.gps.gov/technical/icwg/IS-GPS-200J.pdf)? The
various libraries and operating systems listed deal with none of the
reference time scales (GPS, UTC, or TAI, for that matter) completely and
correctly.
There's no
> Yo Tom!
>
> On Tue, 15 Jan 2019 10:50:10 -0800
> "Tom Van Baak" wrote:
>
> > Nope. All minutes have 60 seconds in Excel. And in Windows. And in
> > Unix/POSIX.
>
> Not quite. Check out "man gmtime" for one way that POSIX represents time.
>
> Specifically:
>
>struct tm {
> [...]
>
On Tue 2019-01-15T10:50:10-0800 Tom Van Baak hath writ:
> Jim -- I'm replying via the LEAPSECS list because we love leap second
> questions here.
>
> List -- Jim is a long-time member of time-nuts, works at JPL, and does
> wonderful stuff.
If you set your POSIX system clock at TAI minus 10
Yo Tom!
On Tue, 15 Jan 2019 10:50:10 -0800
"Tom Van Baak" wrote:
> Nope. All minutes have 60 seconds in Excel. And in Windows. And in
> Unix/POSIX.
Not quite. Check out "man gmtime" for one way that POSIX represents time.
Specifically:
struct tm {
[...]
int tm_sec;
Jim -- I'm replying via the LEAPSECS list because we love leap second questions
here.
List -- Jim is a long-time member of time-nuts, works at JPL, and does
wonderful stuff.
>From Jim Lux:
> I'm working with a variety of things which work in UTC or GPS
> week/millisecond, so we're doing a lot
43 matches
Mail list logo
