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
Martin Burnicki wrote:
> Just a few general thoughts based on an internal note...
And some very good points they were.
> ...The same applies to the time_t type, IMO. If you let the system kernel
> run on TAI or whatever then the time() function still returns a time_t
> data type, but its value
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
Hi all,
Rob Seaman wrote:
> Our Meinberg ref clocks can deliver GPS, UTC, or TAI (and thus other
> derived timescales).
Yes, and the same data formats are used for each of these time scales.
Just a few general thoughts based on an internal note, instead of
replies to individual posts here on
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
12 matches
Mail list logo
