On 2014-10-31 11:40 AM, Warner Losh wrote:
On Oct 31, 2014, at 4:17 AM, Martin Burnicki
wrote:
Magnus Danielson wrote:
On 10/31/2014 02:49 AM, Sanjeev Gupta wrote:
Give it a new name, please. Independent of what the "fundamental
unit" is.
TAI and UTC already exists, but the use of TAI has
Hi Micheal,
On 2014-11-03 02:43 AM, michael.deckers via LEAPSECS wrote:
On 2014-10-31 17:39, Brooks Harris wrote:
Yes. Its primary timescale, sometimes called "PTP Time", more
properly the "PTP
Timescale", is a "TAI-like" counter (uninterrupted incrementi
On 2014-11-03 02:19 PM, Warner Losh wrote:
On Nov 3, 2014, at 11:11 AM, Brooks Harris wrote:
CAUTION about the PTP Epoch. Its not "just nitpicking".
...
We've been advised by PTP experts that A) yes, its confusing, and B) most implementations use a integral-second interpr
On 2014-11-03 03:04 PM, Warner Losh wrote:
On Nov 3, 2014, at 12:53 PM, Brooks Harris wrote:
On 2014-11-03 02:19 PM, Warner Losh wrote:
On Nov 3, 2014, at 11:11 AM, Brooks Harris
wrote:
CAUTION about the PTP Epoch. Its not "just nitpicking".
...
We've been advised
On 2014-11-03 04:50 PM, Warner Losh wrote:
On Nov 3, 2014, at 1:37 PM, Brooks Harris wrote:
On 2014-11-03 03:04 PM, Warner Losh wrote:
On Nov 3, 2014, at 12:53 PM, Brooks Harris
wrote:
On 2014-11-03 02:19 PM, Warner Losh wrote:
On Nov 3, 2014, at 11:11 AM, Brooks Harris
wrote
Hi Zefram,
On 2014-11-04 09:04 AM, Zefram wrote:
Brooks Harris wrote:
The discussion attempts to resolve the question about what the
TAI/UTC relationship was *before* 1972-01-01T00:00:00Z and how this
is related to POSIX and represented by 8601.
The actual historical relationship between TAI
On 2014-11-04 11:53 AM, Gerard Ashton wrote:
Of course Brooks Harris is free to define proleptic UTC any way he pleases
within the confines of a document he has control over, including a post to
this mailing list. But I think the term "proleptic UTC", outside the
confines of a doc
On 2014-11-04 03:35 PM, Steve Allen wrote:
On Tue 2014-11-04T20:27:53 +, Zefram hath writ:
The name "Coordinated Universal Time" and initialism "UTC" are used
in the IAU 1967 resolutions, referring to the rubber-seconds system.
And that resolution explicitly refers to the content of the new
On 2014-11-04 03:27 PM, Zefram wrote:
Brooks Harris wrote:
To call it "UTC" seems a bit of a stretch to me,
but there's no generally accepted name for what Zefram calls
"rubber-seconds era of UTC". Everybody has seized the name, and
attempted to g
On 2014-11-04 04:59 PM, Zefram wrote:
I wrote:
It sounds as though Annex B may contain actual errors, in such things
as the interpretation of POSIX time_t. Good job it's not normative.
I've now seen the actual text of Annex B (thanks to an unattributable
benefactor). Here is my review of it.
IERS publishes this - Its up to date (includes 2014-07-01) as of today
as I access it (2015-01-12).
http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat
I'm not sure when it was updated, maybe with their Bullitin C announcement.
ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
If wo
Opps, sorry, typo - 2015 not 2014 = "Its up to date (includes 2015-07-01)"
On 2015-01-12 10:33 AM, Brooks Harris wrote:
IERS publishes this - Its up to date (includes 2014-07-01) as of today
as I access it (2015-01-12).
http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.da
On 2015-01-12 02:03 PM, Tom Van Baak wrote:
If would really be good if there was one authoritative soure for this,
and that there was a uniform format. Ideally there would be multiple
ways to access it, via text and binary for different architectures. The
might be thought of as a "UTC Metadata AP
Hi Rob,
On 2015-01-12 06:42 PM, Rob Seaman wrote:
On Jan 12, 2015, at 2:53 PM, Martin Burnicki
wrote:
I've suggested at various occasions that the IERS should be the authoritative
source for a leap second file.
There were discussions at both the 2013 and 2011 UTC meetings
Which meetings?
This year's Y2K: 'Leap second' threatens to break the Internet
http://money.cnn.com/2015/01/13/technology/leap-second/index.html
-Brooks
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
On 2015-01-13 01:44 PM, Hal Murray wrote:
If I understand the provenance, BIPM is responsible for maintaining atomic
time and TAI, IERS is responsible maintaining for UT1 and Leap Seconds, and
ITU is responsible for "time dissemination". Whats not so clear, and it
would be reassuring to know,
New Research May Solve Puzzle in Sea Level's Rise
http://www.nytimes.com/2015/01/15/science/earth/new-research-may-solve-a-puzzle-in-sea-levels-rise.html
-Brooks
On 2015-01-15 06:57 AM, Tom Van Baak wrote:
Poul-Henning Kamp writes:
That reminds me, has anybody tried to do the math on climate
On 2015-01-23 10:33 AM, Clive D.W. Feather wrote:
Steffen Nurpmeso said:
|> Well. PHK follows the IERS format which uses the 1st of the month
|> after the leap second, i.e., the second after the leap occurred.
|
|This is an implementation detail. PHK???s choice is as good as the other.
The leap second, deep space and how we keep time
http://www.marketplace.org/topics/world/leap-second-deep-space-and-how-we-keep-time
Much less stupid than many popular reports...
-Brooks
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlis
I agree with Michael.
The (proper) UTC timescale does not exist before 1972-01-01T00:00:00Z
(UTC). That's the beginning of modern (solar) time. There was, or is,
*by definition*, an initial 10 (integral!) second TAI-UTC offset at that
moment. There is no agreed on a term for these initial 10 s
On 2015-01-25 04:57 PM, G Ashton wrote:
Brooks Harris mentioned, at approximately Sun 1/25/2015 21:02 UT, a
"Gregorian timescale". I believe that since in Gregory's time there was no
alternative to making the passage of calendar days agree with the day/night
cycle, we must unders
ized with
Mean Solar Time.
How about "leap_second_epoch" or if the term epoch is undesirable
"leap_seconds_origin" labelled as "leap00"
Ok, I'll re-index to leap0 and have a new cname called origin.leapsec.com.
How's that?
On Jan 25, 2015, at 2:01 PM, Bro
On 2015-01-25 10:04 PM, G Ashton wrote:
Brooks Harris suggested ISO 8601:2004(E), 3.2.1 "The Gregorian calendar" as
a source about the Gregorian calendar. Thanks for the suggestion, but I
consider ISO 8601 to be garbage; it's so bad it makes me dislike the entire
organizati
On 2015-01-26 01:00 AM, Rob Seaman wrote:
"At midnight" is a flexible enough phrase to also handle a second that
*finishes* being introduced at the stroke of midnight :-)
I'm sure you know this as well as anyone, but I caution about the casual
use of terms this way.
I spent many weeks this
On 2015-01-25 03:03 PM, Stephen Scott wrote:
Since UTC is defined by the IERS before 1972-01-01 "beginning_of_utc" is not
appropriate.
This is the beginning of integer leap seconds, not UTC.
As a practical matter of modern timekeeping the UTC timescale started at
1972-01-01T00:00:00Z (UTC). N
Thanks, Steve, You're knowledge about the topic is deep and I thank you
for the excellent reports on your pages. Where "UTC" really came from
may become, or may be, a legend. -Brooks
On 2015-01-26 03:39 PM, Steve Allen wrote:
On Mon 2015-01-26T15:05:55 -0500, Brooks H
On 2015-01-26 04:34 PM, Tom Van Baak wrote:
I spent many weeks this year frantically trying to head off exactly this
problem in a standards body defining a timing protocol. It had been
written to insert Leap Seconds "at midnight", which we know from Rec 460
is not correct.
Brooks,
Please make s
It says -
"Until now the solution has been to introduce a 'leap second', in other
words to stop 'official/scientific' time (Co-ordinated Universal Time,
'UTC'), for one second every so often."
Hold the phone. "to stop 'official/scientific' time"?!? How worrisome is
it that the chair of the c
needs to
credibly, or officially, clarify the fundamentals.
-Brooks
On 2015-01-28 05:09 AM, Poul-Henning Kamp wrote:
In message <54c8b26d.6050...@edlmax.com>, Brooks Harris writes:
It says -
"Until now the solution has been to introduce a 'leap second', in oth
On 2015-01-28 05:31 AM, m...@lumieresimaginaire.com wrote:
Oops - that last one got away while I was trying to quit HTML!!!
Le 28.01.2015 11:09, Poul-Henning Kamp a écrit :
In message <54c8b26d.6050...@edlmax.com>, Brooks Harris writes:
It says - "Until now the solution
On 2015-01-28 05:49 AM, Brooks Harris wrote:
On 2015-01-28 05:31 AM, m...@lumieresimaginaire.com wrote:
Oops - that last one got away while I was trying to quit HTML!!!
Le 28.01.2015 11:09, Poul-Henning Kamp a écrit :
In message <54c8b26d.6050...@edlmax.com>, Brooks Harris
On 2015-02-05 01:51 PM, Steffen Nurpmeso wrote:
Kevin Birth wrote:
I'm no longer that integrated, but from earlier years i know no
Muslim that uses software for that, not even watches.
Some of my Muslim friends most certainly do -
http://www.muslimpro.com/
-Brooks
__
my Muslim friends and students find themselves beginning and ending Ramadan
on different days. This results in some feasting while others are fasting.
Cheers,
Kevin
From: LEAPSECS [leapsecs-boun...@leapsecond.com] on behalf of Brooks Harris
[bro...@
On 2015-02-05 05:53 PM, Kevin Birth wrote:
If one can read Japanese (which I can do with great difficulty and veeey
slowly), one notes that the official Japanese announcement refers to the IERS
and the leap second policy, but it translates UTC 23:59:60 on June 30 into the
local time of 8:5
Hi Tom,
On 2015-02-05 09:18 PM, Tom Van Baak wrote:
Many aspects of "local time" or "civil time" are left to "common
practice" which is not good enough to expect uniform inter-operable
implementations.
Brooks, can you give some examples?
I'm not sure what examples you mean, but perhaps compar
On 2015-03-03 09:23 PM, Steve Allen wrote:
On Wed 2015-03-04T00:04:10 +, Tony Finch hath writ:
They have different epochs:
TAI: 1958-01-01 T 00:00:00 Z
PTP: 1970-01-01 T 00:00:00 Z
GPS: 1980-01-06 T 00:00:00 Z
Using ISO 8601 style date and time representation on the TAI timescale
and on
On 2015-03-04 02:12 AM, michael.deckers via LEAPSECS wrote:
On 2015-03-03 21:05, Martin Burnicki wrote about
negative leap seconds:
In the 7 year interval where no leap second was required/scheduled I
heard
several people saying we might have needed a negative leap second.
Fortun
On 2015-03-04 07:28 AM, Steffen Nurpmeso wrote:
"Tom Van Baak" wrote:
|http://gpsworld.com/beidou-numbering-presents-leap-second-issue/
Ok, but if engineers don't even get enough time from the business
people to read manuals before they code the software then all bets
are off. From a coders
On 2015-03-05 08:39 AM, Martin Burnicki wrote:
Tony Finch wrote:
Martin Burnicki wrote:
I agree, but as I've tried to point out above I think a better
project design
would have been to use TAI instead of GPS time. PTP works natively
with TAI,
and you can easily convert between he two scale
a multi-page essay and I never quite completed it. I'll try to
finish that, but here I'll try to quickly answer your comments.
On 2015-03-05 01:29 PM, Zefram wrote:
Brooks Harris wrote:
The first part of that sentence is correct "The PTP epoch is 1
January 1970 00:00:00 TAI"
On 2015-03-06 08:30 PM, Paul Hirose wrote:
On 2015-03-06 11:04, Brooks Harris wrote:
The "rubber-band era" is
just entirely irrelevant. Its historically interesting, and may be
required for some special application concerning that period, but for
practical "UTC-like" tim
Hi Gerard,
On 2015-03-07 12:04 PM, G Ashton wrote:
Brooks Harris wrote on Saturday, March 7, 2015 11:50 :
.
.
"The challenge I'm trying to solve is to provide a deterministic timekeeping
and labeling scheme for date and time *after* 1972-01-01T00:00:00Z (UTC) =
1972-01-01T00:00:10 (
Hi Steve,
On 2015-03-07 03:01 PM, Steve Allen wrote:
On Sat 2015-03-07T14:14:07 -0500, Brooks Harris hath writ:
It is typically warned that date and time before 1972 cannot be
accurately represented with NTP or POSIX, for examples.
I would say that for PTP
* all seconds are always SI seconds
On 2015-03-07 06:50 PM, Joseph Gwinn wrote:
On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote:
In the discussions I've been involved with many people argued
strenuously "we don't care about the past, only accurate date-time
going forward!". The reason I'm choos
On 2015-03-08 12:45 PM, Zefram wrote:
Brooks Harris wrote:
that allows the epochs to slip with each Leap Second in the manner
NTP and POSIX do, which is, as you call it, "scalar".
I think you understand by the word "scalar" something very different from
what I mean. By &qu
On 2015-03-08 01:09 PM, Zefram wrote:
Brooks Harris wrote:
It seems to me NTP and POSIX as well as other timescales concerned
with "civil time", are essentially disconnected from "reality",
expressing "idealized" measurement scales.
That's very much what the
On 2015-03-08 03:43 PM, Zefram wrote:
Brooks Harris wrote:
On 2015-03-08 12:45 PM, Zefram wrote:
Brooks Harris wrote:
In PTP, at the PTP Epoch, 1970-01-01T00:00:00 (TAI), currentUtcOffset
= 10s.
Where do you get this idea from? You've cited no source for it.
You appear to have pluck
On 2015-03-08 05:00 PM, Warner Losh wrote:
On Mar 8, 2015, at 10:24 AM, Brooks Harris wrote:
I think the only way the industry can eventually converge on reliable "civil time" representation
is to refine the underlying time mechanisms in POSIX in some manner that allows a migration
On 2015-03-09 08:40 AM, Tony Finch wrote:
Brooks Harris wrote:
On 2015-03-07 03:01 PM, Steve Allen wrote:
I would say that the intent NTP and POSIX is to correspond to civil
time in contemporary use. Therefore, for dates before 1972-01-01
NTP and POSIX are counting seconds of UT.
This
On 2015-03-09 02:10 PM, Tom Van Baak wrote:
leap59 and leap61 are Leap Second announce signals, set 12 hours prior
to the insert. There has been discussion about when the official
announcements and expiration should be announced. ITU Rec 460 says
"...at least eight weeks in advance". PTP can't do
Overall he seems to make a good philosophical argument why solar time is
good for humans. But his conclusion seems confused.
"... let the airlines and the Internet companies use TAI".
Ah, the airlines already use GPS (TAI-like) for navigation, and "local
civil time" for scheduling, while the "
Hi Tom,
On 2015-03-12 02:57 AM, Tom Van Baak wrote:
Brooks,
A couple more comments on your questions.
Many timekeeping systems seem to be designed for only indicating "now"
counting forward, including NTP, POSIX, and PTP, taking short-cuts to
avoid supplying full Leap Second and local-time me
On 2015-03-12 11:57 AM, Stephen Colebourne wrote:
On 12 March 2015 at 05:21, Steve Allen wrote:
On Wed 2015-03-11T11:04:57 -0700, Tom Van Baak hath writ:
The entire purpose of UTC is to provide a single timescale for all
human-related activity.
And UTC has failed miserably. POSIX says UTC ha
Hi Tom,
On 2015-03-12 09:50 PM, Tom Van Baak wrote:
Brooks wrote:
Many timekeeping systems seem to be designed for only indicating "now"
counting forward, including NTP, POSIX, and PTP, taking short-cuts to
avoid supplying full Leap Second and local-time metadata.
Warner wrote:
A clock doesn’
Hi Rob,
My Chrome browser opens with either.
http://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.dat
https://hpiers.obspm.fr/iers/bul/bulc/Leap_Second_History.dat
I don't know Python much, but out of curiosity looked up http v.s.
https. Try calling class httplib.HTTPSConnection() instead o
On 2015-04-27 03:22 AM, Harlan Stenn wrote:
"Poul-Henning Kamp" writes:
https://en.wikipedia.org/wiki/Indiana_Pi_Bill
What a great idea! Simplification! Why stop there? If we prohibit the
use of Real values we could just round off PI to 3 - much simpler!
Following that we could do away with th
ASX Management of the International Leap Second
http://www.sfe.com.au/content/notices/2015/0291.15.03.pdf
-Brooks
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Hi Tom and Rob,
On 2015-05-30 06:05 PM, Tom Van Baak wrote:
Perhaps one should point out that local midnight is pretty much the worst
possible time for astronomers to accommodate such a change?
Hi Rob,
Oh, you're such an old earth+photon guy. Ask any space probe, neutrino, or
gravitational as
On 2015-05-31 02:41 AM, Poul-Henning Kamp wrote:
In message <556a6bd2.50...@edlmax.com>, Brooks Harris writes:
I can't find any authoritative announcement or statement to this effect
>from Microsoft, [...]
Please note that this is *only* about Microsofts Azure cloud
On 2015-05-31 03:57 AM, Brooks Harris wrote:
On 2015-05-31 02:41 AM, Poul-Henning Kamp wrote:
In message <556a6bd2.50...@edlmax.com>, Brooks Harris writes:
I can't find any authoritative announcement or statement to this effect
>from Microsoft, [...]
Please note that
On 2015-05-31 04:40 AM, Poul-Henning Kamp wrote:
In message<556abecf.2050...@edlmax.com>, Brooks Harris writes:
My question is, if Azure is doing this, what is Windows itself doing?
No.
for that no new information is available and the most recent
guidance was that &quo
Hi Poul-Henning,
On 2015-05-31 03:33 PM, Poul-Henning Kamp wrote:
In message <556b5d76.6000...@edlmax.com>, Brooks Harris writes:
Most Windows boxes don't run NTP.
I don't think that's true. As far as I know, Windows, either personal or
Server versions, synch
Hi Tom,
On 2015-05-31 07:23 PM, Tom Van Baak wrote:
Hi Brooks,
I don't know enough about Windows timekeeping in general or versions of Windows
in particular to give you any authoritative answer. But here's one data point
that might help clarify what you and PHK are talking about.
On Windows
On 2015-06-01 12:37 PM, Tom Van Baak wrote:
Tom Van Baak said:
On a positive note, this means one could actually experience more than one
Windows non-leap-second on June 30. Maybe this year I should try to
celebrate the leap second twice, in Mountain and in Pacific time. Time to
pull out the roa
On 2015-06-01 03:25 PM, Steve Allen wrote:
On Mon 2015-06-01T12:05:08 -0700, Tom Van Baak hath writ:
Can you send me a definitive URL with global TZ rules so I can
grep|sort|uniq to get a feel for when DST transitions occurs? I guess
I thought it always was 2 am local (which implies jumps from
On 2015-06-01 02:46 AM, Poul-Henning Kamp wrote:
In message<556bfd47.4050...@edlmax.com>, Brooks Harris writes:
Multiply this by 250 million [1] PC's still happily running XP
and you can better understand why Microsoft hasn't been that
interested in leap seconds, NTP,
On 2015-06-02 04:25 PM, Poul-Henning Kamp wrote:
In message <556d8c59.9040...@edlmax.com>, Brooks Harris writes:
A lot of Windows machines are doing things where you would expect
people to care about leap-seconds: Nuclear power plants control
systems, Air Traffic Control com
On 2015-06-03 10:55 AM, Poul-Henning Kamp wrote:
In message <556f0c92.4020...@edlmax.com>, Brooks Harris writes:
You're saying this to the bloke who implemented a prototype adaptive
optics solution for the ESO ELT on a plain, unmodified FreeBSD
kernel ?
I didn't
On 2015-06-28 10:01 AM, Poul-Henning Kamp wrote:
In message , Rob Seaman writes:
PHK and others make good points, but I’m still trying to
get past the "binary-file equivalent of XML”.
You think that is bad ? Then google "JSONx"...
Everyone loves standards, and everyone believes th
On 2015-06-28 07:31 AM, Hal Murray wrote:
Can somebody do the math to figure out what range of dates would be
supported by a signed 8-octet integer in nanoseconds centered on
2001-01-01?
64 bits of nanoseconds covers 584 years
divide by 2 if you want signed (63 bits)
Looks to me they mean 128
On 2015-06-29 02:19 AM, Hal Murray wrote:
Looks to me they mean 128 bits?
How did you get that?
Er, by not thinking very clearly :-\
supported by a signed 8-octet integer in nanoseconds centered on
8*8 is 64. I didn't see anything about using two of them.
Right. My obvious error.
POSIX
Problem solved!
On 2015-06-29 01:47 PM, Tom Van Baak wrote:
The folks at http://www.timeanddate.com/time/leapseconds.html have a leap
second animation on the top right side of the page. I'm not sure how it
displays for you, but attached are some screen shots on my end. Cute.
/tvb
__
On 2015-06-30 05:06 PM, Warner Losh wrote:
I'm getting hate mail from a former job. Seems like 7 years ago I put some
stupid code into the tree. It was there for only a year or two, but today it
took out a few really old systems that were still running this code...
How's your day going?
I'm e
I synced my Windows 7 using my own SNTP implementation about two minutes
before 8PM New York (Eastern Daylight Time). The SNTP data reported the
Windows within 0.0004 of the NTP - pretty good! I watched the Windows
clock carefully. It counted up 8:00:56, 57, 58, 59 as expected with a
nice one s
Thanks Steve, I was wondering what was going on (but lazily didn't go
hunting).
Did the question change? It seems like the current statement is more
elaborate, if seemingly somewhat tangled, from earlier versions?
...LEAPSECS/ITU-R/R15-WRC15PREPWORK-C-0008!!PDF-E.pdf
WRC-15 agenda item 1.14
Its those evil Leap Seconds!
Earth Blamed for Cracks in Moon
http://www.nytimes.com/2015/09/22/science/earth-blamed-for-cracks-in-moon.html
-Brooks
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapse
Hi Steve,
I just wanted to compliment you on the huge about of work in these
pages. Its a fantastic collection of facts and your explanations and
commentary are extremely helpful. Well done and thank you.
-Brooks
On 2015-11-08 10:15 PM, Steve Allen wrote:
On Sun 2015-11-08T18:51:37 -0800, H
LEAPSECS is back in business!
-Brooks
On 2015-11-18 12:25 AM, Steve Allen wrote:
Last Thursday the chair of WRC-15 Special Working Group 5A3 submitted
Temporary Document [68]
Proposals relating to agenda item 1.14
http://www.itu.int/md/R15-WRC15-151102-TD-0068/en
No further meetings of SWG 5A3
Hi John,
I like the idea in general, even if its a solution in search of a
problem. I think many fields would find it useful if it found agreement
and acceptance.
Consider this:
For your "specification" I'd suggest you define the data type
generically so it can be implemented, represented,
On 2016-04-25 12:54 AM, John Sauter wrote:
On Sun, 2016-04-24 at 20:33 -0400, Brooks Harris wrote:
Hi John,
I like the idea in general, even if its a solution in search of a
problem. I think many fields would find it useful if it found
agreement and acceptance.
Consider this:
For your
On 2016-04-25 11:11 AM, John Sauter wrote:
On Mon, 2016-04-25 at 09:40 -0400, Brooks Harris wrote:
Hi John,
"understood and widely used ", yes. Standardized by an international
standards organization, I'm not sure. Anyone know of one? There's a
lot of things in timekeepin
Hi,
One quick comment -
Couldn't we computer folks start to use the very sensible ISO 8601 date
format? For example
EXPIRATION_DATE=2457751 # 2016 12 28
-Brooks
On 2016-04-27 11:14 AM, John Sauter wrote:
I have written the sample code that Hal suggested, along with its data
file. I attach
On 2016-04-27 11:53 AM, John Sauter wrote:
On Wed, 2016-04-27 at 11:41 -0400, Brooks Harris wrote:
Hi,
One quick comment -
Couldn't we computer folks start to use the very sensible ISO 8601
date format? For example
EXPIRATION_DATE=2457751 # 2016 12 28
-Brooks
I used Day Month Year
On 2016-04-27 05:11 PM, John Sauter wrote:
On Wed, 2016-04-27 at 15:13 -0400, Brooks Harris wrote:
I understand. But its always seemed to me those old formats should
be obsolesced, that ISO 8601 presented an attractive alternative,
that the YMDhms order made such good sense. Of course
Oh that is just too cool! Well done!
-Brooks
On 2016-05-18 01:09 PM, Tom Van Baak wrote:
Slightly off-topic, but this may be of interest to some of you who aren't also
on the time-nuts list.
Tonight, Wednesday evening (May 18) look for a TV show on National Geographic or PBS
called "Genius by
"WASHINGTON, DC -- On December 31, 2016, a "leap second" will be added
to the world's
clocks at 23 hours, 59 minutes and 59 seconds Coordinated Universal Time
(UTC). This
corresponds to 6:59:59 pm Eastern Standard Time, when the extra second
will be inserted at the
U.S. Naval Observatory's Mast
n, DC will insert
this positive Leap Second in the Eastern Standard Time (UTC-05:00)
timescale on 2016-December-31 immediately following the second labeled
06:59:59 pm (18:59:59) and it will be labeled 06:59:60 pm (18:59:60).
-Brooks
On 2016-07-11 09:45 AM, Brooks Harris wrote:
"WASHINGTON
Hi Tom,
A couple questions and thoughts concerning standards and nomenclature -
On 2016-07-20 01:08 AM, Tom Van Baak wrote:
Hi Mark,
Three comments:
1)
I recall this is a known problem in the Z3801A status reporting, and possibly
other GPS receivers of that era as well. It stems indirectly f
On 2016-07-20 11:27 AM, Martin Burnicki wrote:
Brooks Harris wrote:
On 2016-07-20 01:08 AM, Tom Van Baak wrote:
I recall this is a known problem in the Z3801A status reporting, and
possibly other GPS receivers of that era as well. It stems indirectly
from a change years ago in how far in
Hi Warner,
On 2016-07-20 11:34 AM, Warner Losh wrote:
On Wed, Jul 20, 2016 at 8:23 AM, Brooks Harris wrote:
Hi Tom,
A couple questions and thoughts concerning standards and nomenclature -
On 2016-07-20 01:08 AM, Tom Van Baak wrote:
Hi Mark,
Three comments:
1)
I recall this is a known
Hmmm. You wonder why they chose 2000 seconds, which gives a nice round
number of seconds for the duration: 2000/60=3.3... :-|
So, now there are at least 3 different smears in use by major providers
to "hide" the Leap Second from downstream systems that might be upset by
it. This produces indet
Hi Tom, Stephen and Stephen;
Adding to Stephen Scott's comments...
On 2016-09-24 11:39 AM, Stephen Scott wrote:
Hello Tom, Stephen;
On 2016-09-24 08:26, Tom Van Baak wrote:
Stephen,
As I've been saying for years, what we need (desperately) is a
standard for smearing, aka 86400 subdivision
Warner,
On 2016-09-24 06:02 PM, Warner Losh wrote:
On Sat, Sep 24, 2016 at 3:46 PM, Hal Murray wrote:
tvb said:
Smearing is fine. It's a practical solution to an intractable problem. But
forcing everyone to implement it the exact same way misses the point. You
can't create a standard for your
Hi Gerry,
On 2016-09-25 07:58 AM, GERRY ASHTON wrote:
The Microsoft Azure approach of moving the leap second to local
midnight has been discussed.
I suppose you mean at LEAPSECS? If so I've missed that and be interested
in the reference. I'd be interested in any other discussions of it as we
cking 'next':
https://pairlist6.pair.net/pipermail/leapsecs/2015-May/005920.html
/tvb
- Original Message -
From: Brooks Harris
To:leapsecs@leapsecond.com
Sent: Sunday, September 25, 2016 11:19 AM
Subject: Re: [LEAPSECS] Bloomberg announced its smear
Hi Gerry,
On 2016-09-25 07
Hi Tony,
On 2016-09-26 09:52 AM, Tony Finch wrote:
Brooks Harris wrote:
Note too the discussions of how they increment the smear so as to
not upset some receiver's PPL.
Is anyone other than Google doing that? All the other smears I recall
(UTC-SLS, Amazon, Bloomberg) have been piec
On 2016-09-26 10:23 AM, Tony Finch wrote:
Brooks Harris wrote:
The short of it is Windows behave just like POSIX as far as I can tell,
except its epoch, represented as struct FILETIME, is 1601-01-01T00:00:00
(UTC-like), which is, apparently the COBOL epoch (I didn't track down
the refer
Hi Tom,
Seems to me this conversation is drifting back and forth between objectives.
It started out to explore if a common method of smear could be found for
purposes as Google, AWS, and Bloomberg are using it. As I understand it,
the whole point there is to "hide" the Leap Second from the ver
Hi John,
On 2016-10-09 12:41 PM, John Sauter wrote:
On Sat, 2016-10-08 at 15:58 -0600, Warner Losh wrote:
On Sat, Oct 8, 2016 at 2:43 PM, Steve Allen wrote:
On Fri 2016-10-07T11:48:25 -0600, Warner Losh hath writ:
Accurate, Traceable, and Verifiable Time Synchronization for
World
Financial Ma
On 2016-10-09 11:32 PM, John Sauter wrote:
On Sun, 2016-10-09 at 15:12 -0400, Brooks Harris wrote:
I took the lack of mention of leap seconds to mean that leap
seconds
ere not a problem. The output of the NISTDC units is an
astonishingly
accurate 1 pulse per second. That feeds NTP, which
1 - 100 of 283 matches
Mail list logo
