On 2017-10-23 06:31 PM, Warner Losh wrote:
On Mon, Oct 23, 2017 at 3:42 PM, Brooks Harris > wrote:
On 2017-10-23 02:07 PM, Warner Losh wrote:
Never has been really, but it was the objective for centuries.
Local time is obviously a
On Mon, Oct 23, 2017 at 3:42 PM, Brooks Harris wrote:
> On 2017-10-23 02:07 PM, Warner Losh wrote:
>
> Never has been really, but it was the objective for centuries. Local time
> is obviously a gross approximation, but a very useful one. Before atomic
> time, navigation time
On 2017-10-23 02:07 PM, Warner Losh wrote:
On Mon, Oct 23, 2017 at 11:37 AM, Brooks Harris > wrote:
On 2017-10-23 09:58 AM, Rob Seaman wrote:
Multiple timescales exist now for multiple purposes. Multiple
timescales
"UT1 is an artificial construct of averaging local time as well, with the
seasonal variations subtracted out."
No, that is wrong. Perhaps you are thinking of the (defunct) time scale UT2.
UT1 gives us the true orientation of the Earth in space as measured (now)
directly by space geodetic
In message <59ee28f3.60...@edlmax.com>, Brooks Harris writes:
> To me, the frustrating thing about the discussion at ITU and elsewhere
> is the apparent outright refusal to consider a "second timescale". It is
> considered and then dismissed out of hand in:
The reason is very simple:
On Mon, Oct 23, 2017 at 11:37 AM, Brooks Harris wrote:
> On 2017-10-23 09:58 AM, Rob Seaman wrote:
>
>> Multiple timescales exist now for multiple purposes. Multiple timescales
>> will exist under all scenarios. Debasing Universal Time is not a
>> solution to any "real world"
> On October 23, 2017 at 1:37 PM Brooks Harris wrote, in
> part:
>
> The irreconcilable difficulty arises from UTC being a modification of
> the Gregorian calendar algorithm. The world (mostly) uses Gregorian, but
> then along comes this unpredictable and irregular Leap
On 2017-10-23 09:58 AM, Rob Seaman wrote:
Multiple timescales exist now for multiple purposes. Multiple timescales
will exist under all scenarios. Debasing Universal Time is not a
solution to any "real world" problem. If you want a new timescale,
define a NEW timescale.
Indeed.
To me, the
On Mon, Oct 23, 2017 at 9:00 AM, Poul-Henning Kamp
wrote:
>
>
> > By that logic one should avoid intervals spanning the end of February
> > because of leap days, and avoid any periods in the spring or fall (in
> > either hemisphere) that might span local DST
On Mon, Oct 23, 2017 at 7:28 AM, John Sauter <
john_sau...@systemeyescomputerstore.com> wrote:
> On Sun, 2017-10-22 at 23:46 -0600, Warner Losh wrote:
> >
> >
> > On Sun, Oct 22, 2017 at 11:02 PM, John Sauter > computerstore.com> wrote:
> > > On Sun, 2017-10-22 at 17:53
> By that logic one should avoid intervals spanning the end of February
> because of leap days, and avoid any periods in the spring or fall (in
> either hemisphere) that might span local DST transitions, [...]
That is balderdash, and you know it:
We know exactly when leap-days happen,
Well, there's an experiment for the next leap second. Watch the 10 MHz
and PPS coming out of a GPSDO with an oscilloscope set to trigger at
midnight UTC. I think our Rigol accepts an external trigger. The
Meinberg can generate one at 23:59:59. Two second window.
After a couple of decades of this
> By that logic, one should avoid any interval that includes June 30 or
> December 31, since such an interval might include a leap second.
John,
Right. Exactly. Which is why some systems that need to keep time reliably, or
that integrate frequency to get time, avoid leap seconds altogether.
See below.
On 10/23/17 6:28 AM, John Sauter wrote:
> On Sun, 2017-10-22 at 23:46 -0600, Warner Losh wrote:
>>
>> On Sun, Oct 22, 2017 at 11:02 PM, John Sauter > computerstore.com> wrote:
>>> On Sun, 2017-10-22 at 17:53 -0700, Steve Allen wrote:
The BIPM has
On Sun, 2017-10-22 at 23:46 -0600, Warner Losh wrote:
>
>
> On Sun, Oct 22, 2017 at 11:02 PM, John Sauter computerstore.com> wrote:
> > On Sun, 2017-10-22 at 17:53 -0700, Steve Allen wrote:
> > >
> > > The BIPM has contributed
> > > CGPM draft Resolution "On the
15 matches
Mail list logo