buggy standards with a huge installed base getting
>fixed?
Yes, plenty.
Building codes. Electrical codes. Traffic codes.
The deciding factor is always number of people killed and maimed.
... Or the rich loosing money, that always gets political action.
--
Poul-Henning Kamp
d"...
Reported to me from the hall-way-track at the last WP7A meeting:
"The main drive to ditch leap-seconds comes from the only
country ever to flunk Metric-101"
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC
oth choices, but I'd probably go with Googles
to avoid the sharp corners.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by inco
http://iopscience.iop.org/0295-5075/110/1/10002/article
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
ts will remove leaps from GMT as well,
so there still won't be any difference, and people will in all likelyhood
still confuse them.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never
going on here is that the biggest financial hub in the USA doesn't
know the difference between UTC and GMT.
That just shows that timekeeping is already far to complex for normal
people and that simplification and fewer timescales is the way to go.
--
Poul-Henning Kamp | UNIX since Zi
.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
LEAPSECS mailing list
ronize computer clocks, in particular it defines the
measurement unit on this scale to be 2^-32 SI second and the handling
of epoch roll-overs (every 2^32 SI seconds).
But more importantly, when we get to the point were we are arguing
over the meaning of common well known words we might as well
r his opinion, which as
others have pointed out, interfaces badly with reality.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice w
In message <20150206134600.gl61...@davros.org>, "Clive D.W. Feather" writes:
>Poul-Henning Kamp said:
>> The specification of local time is in (super-/sub-)national
>> legislation.
>>
>> In EU it is in the directive about Daylight Savings Ti
very good argument for the positioin notion that unelected
and unrepresentative scientists should not get to decide where and
when the Sun is supposed to be in the sky above.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
ion.
In EU it is in the directive about Daylight Savings Time.
Most such legislation says "UTC +/- $integer_hours" and it follows
trivially that leapseconds happen at localtime of +/- $integer_hours.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | T
und and mostly populated I have a hard time seeing any
other longitude offering significant relief from this problem.
If one takes a strictly democratic view on this, China gets to veto
quite a wide slab of longitudes, given that they have the timezone
with most people in it.
--
Poul-Henning Kam
would happen at 8 or 9am
on any day of the week, ie: during the busiest hour of traffic,
on roads, rails and in the air ?
That's what a similar "dialog" would warn about, if it were conducted
in China or Japan.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@fr
http://xkcd.com/1481/
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence
In message , Rob Seaman writes:
>On Jan 28, 2015, at 1:34 PM, Poul-Henning Kamp wrote:
>
>> "Derives from" is not a "physical reality", it's merely a social custom.
>
>So many replies to choose from [...]
... all of them unresponsive to my com
In message , Rob Seaman writes:
>And length of day most assuredly derives from the synodic day,
>i.e., mean solar time. Is there not one fewer day in the year than
>sidereal rotations?
"Derives from" is not a "physical reality", it's merely a soci
ll, these guesses/estimates are not inferior to
the ones you already list ?
Listing them all would be sound science, and maybe the good ol'
"Trust the median" will eventually help us, given enough estimates ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org
rt your opinions.
Likewise, as for your personal "physical reality" isn't trumping
anything, unless you're also the one paying the piper.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-taho
ilover is possible, in both the hot and cold spare case.
GPS is actually the easy case, because the announce leap seconds
months in advance.
DCF77 gives you only one hour notice about the leapsecond.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC
at we can ever implement
leap-seconds in a responsible fashion, if even a such persons do
not grasp what it is ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD s
even demanding, that the
pedestrians upgrade their programming skills is not credible however.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately
d noises".
It would certainly improve things a lot, because clients, which may
upgrade at a different rate than servers, could just ignore any
server which indicates a leapsecond.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeB
be garbage; it's so bad it makes me dislike the entire
>organization.
Fortunately your personal tastes or distastes have little impact
on what is the normative definition. Like it or not, 8601 it is.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP
In message , Tim Shepard writes:
>What should "next.leapsec.com" point at after July 1, 2015 in the few
>weeks before Bulletin C number 50 is issued?
It should point to C49 until C50 is published.
And I think it should be bulletin-c.$domain
--
Poul-Henning Kamp
fashion, [...]
Nope. Only if the probability of bit-flipping depends on the data,
but that has nothing to do with CRC.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to ma
t the number of
>leap seconds, rather than just tell a general lie about an IP address,
>the CRC won't protect you.
Sorry, I somehow got the sign flipped on what you said.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeB
most
recent bulletin C.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
.
Uhm, that crafty DNS server would surely be able to come up with a new
non-eyebrow-raising CRC8 value as well...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to mal
undoubtedly be overkill.
The CRC protects against the common risks (lying DNS resolvers), we
don't need more than that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-t
he old
>record had to be restored.
It's the difference between "have not been told that X will happen"
and "have been told that X will not happen."
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committe
In message , Tony F
inch writes:
>If you are only broadcasting the next or just recently occurred leap
>second,
What I'm doing is really making Bull-C available with a trivial
DNS query.
It is exactly the info from Bull-C I want to encode, no more, no less.
--
Poul-H
c.
>
>What do "free WIFI" portals do with TXT records?
A fair number of them seem to return "A $MYGW" for *any* DNS query.
>What do they do with NTP requests?
They generally seem to allow NTP through once you're logged in.
--
Poul-Henning Kamp | UNI
ity, I would send both an IPv6 and IPv4 DNS record as
response, hoping that at least one of them makes it through.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Neve
atmospheric
warming, because it seems a lot of the heat went into the oceans
instead. (And that should worry people a LOT!)
3. The coincidence is that the volcanoes may connect two rather
different phenomena on a decadal scale.
--
Poul-Henning Kamp | UNIX since Zilog Zeu
n any API
to execute a custom DNS query.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be exp
g both ways,
as a matter of stresses in one direction and lubrication in the other.
As interesting as this might be intellectually, if melting ice-sheets
case an order of magnitude more volcano eruptions leap seconds will
not be our most pressing problem.
Poul-Henning
--
Poul-Henning Kamp |
cused on how NTP/PTP clients will be able to get/validate
leapsecond information efficiently and reliably.
>Unless there is an overriding value in efficient encoding,
There is. getaddrinfo(3) is almost always available and works
about as well as any protocol on the internet can work.
--
ng these
numbers as source or destination addresses.
2. I live in a civilized society and have repeatedly heard lawyers
from the US deflate once they realized that they didn't known
what the relevant laws said, much less the language to find out.
--
Poul-Henning Kamp | UNIX
In message <89326.1421483...@critter.freebsd.dk>, "Poul-Henning Kamp" writes:
>I played a bit with the idea this morning, and I think this is how I would
>do it:
>
> +---+---+-+-+---+
> |1 1 1 1|M M M M M
Attached is a proof of concept in python.
You can poke the result at my test-domain "leap.net-tid.dk"
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC
belief
that you can trust these fine gentlemen ?
I doubt it.
The ideal situation would be that IERS and the major timelabs agreed
to do this, so that a DNS lookup of leapsecond.iers.org,
leapsecond.nist.gov, leapsecond.ptb.de and so an all did the same
thing, and people could pick who they trust
eekend regarding the CRC checksum...
The CRC is there to detect when DNS replies are rewritten to
point everything at captive portals, as is the case on a lot
of "free WIFI" networks etc.
Your idea offers no way to detect that...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.2
(1...12)
8 bit signed int before count
2 bit signed int (after - before) count
10 bit CRC-10
Obviously the IPv6 mapping can be even more robust.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committ
lookup and get the TTL and don't need to do another
lookup until the TTL expires.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice
rder of a millisecond per year.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by inc
t has been documented since at least NTPv3 a
couple of decades ago.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
_
In message <20150114115758.gvgcdclg%sdao...@yandex.com>, Steffen Nurpmeso write
s:
>"Poul-Henning Kamp" wrote:
> |
> |In message <54b621b5.1080...@rubidium.dyndns.org>, Magnus Danielson writes:
> |
> |>> About one year ago I contac
rks almost everywhere.
>
>That would be one of many ways that it should be distributed.
Absolutely.
But the reason why DNS would be nice is that it's lightweight.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD commit
eally useful would be if they provided the current
leapsecond count and the date of the next (if known) via DNS.
DNS because it has built in caching and works almost everywhere.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD co
l sense, but in these days of "cyberwar
worries" a lot of people will not be legally able to rely on it anymore...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to
23°59' and 24°00' had
sixtyone seconds once every other year or so.
"minutes" and "seconds" are fractions of 60 and have been so since
babylonian times for minutes and since 13-mumble for seconds.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.o
tion of a second.
But today the "paper" is used ti signify things which needlessly
takes weeks and months.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice
algorithm (ie: one which reduces a clocks weight earlier
in time for something it did later.)
For all practical purposes we could dismiss with paper clocks
and go real time, but I'm sure astronomers will tell us that
would do things to the cows milk or something...
--
Poul-Henning Ka
;.
You mean the same way leapseconds redefine "minute" by making
them have the counter intuitive numbers of seconds ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribu
M-DD, for "UTC" read ${NEW_UTC_NAME}"
would clear the hurdle they erected in one line.
So even if the #2 crowd wins their name-change battle, they
would still loose the war.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TC
dy has support for it, and the data received by NTP
>is then clear and complete.
And because the typical update cycle for the time-zone database is highly
erratic and nonexistent on many legacy platforms.
If leap-seconds were announced 10 years in advance it would be different.
--
Poul-Henning
sn't care or try to make sense of what the numbers might mean.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be e
if you had written some ...EST or ...DST, and
that would take you into the murky swamp of the olsen timezone
database.
By explicitly stating the UTC offset numerically, 8601 decouples
it from any cultural basis it might have had and becomes a standalone
representation of a moment in time.
--
ot represent daylight saving nor time zones.
I'm told this was by design.
The intent was that you could always use an 8601 string without
reference to "external cultural databases".
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 9
which would make it anybodys guess what will happen.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
That said, I'm not sure I fully buy Toms prediction yet, 35 years
isn't that long of a data-set
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what ca
ood drive
current to the vibrator motor.
The missing SIM card would be the key here: Without that the phone
doesn't set its clock from the network.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-t
t;define the second", the
explicitly picked up the SI standard second.
You have no idea how tired I'm getting of you continuously spewing
this kind of manipulative crap...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
on the three times I've looked at it today.
http://xkcd.com/now
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what c
In message , "Richard B. Langley"
writes:
>Guess this is meant to be used with the image printed out and then
>the map and time zones circle cut out and then pinned at [...]
No, it's intended to be used on-line, where it is supposedly always
in the right configuration.
o vague and
fuzzy that we should naturally expect people to use it carelessly
and without any formal definition.
Sort of like "RS-232"...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-ta
was a leap second.
>
>My understanding wasn't that all Linux kernels crashed.
Only the ones which cared enough about time-keeping to run NTPD.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-
ing a quick and swift death back when
that was first proposed.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately b
In message <20140119182454462945.77293...@comcast.net>, Joseph Gwinn writes:
>This is the bounding case. ATC systems typically do not jump at the
>leap, they slide over 10 seconds or so.
In Denmark they go hands off "until stuff look normal again".
--
Poul-Henning K
l the way
>through the system. Conversely, it potentially exposes parents
>to an additional year of childcare costs.
Yes, similar 'red lines' exist in most countries.
The point I made was that the state does not care what side of that
line any one particular kid lands.
--
Poul-Hen
them to figure out when to get
out of bed in their local realities.
My experience is that people react with surprise initially, but
that once you've "broken them in" and explained why you do it, there
are far fewer "oops I missed the time" incidents, in particular
aro
In message <20140119164807.ga19...@ucolick.org>, Steve Allen writes:
>If the leap seconds were placed into a similarly inconsequential part
>of the interfaces then the applications could be similarly wrong about
>leap seconds yet life would go on.
They are. It does. So far.
-
n the morning, despite the fact that they likely were
born later in the day -- or maybe even in a different timezone.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute
In message <71d95256-adee-4323-ade4-b945643ab...@batten.eu.org>, Ian Batten wri
tes:
>
>On 18 Jan 2014, at 11:28, Poul-Henning Kamp wrote:
>>
>> For instance I doubt you'll find any UK politician willing to push
>> a s/GMT/$whatever/ legislation since that wi
power.
The question is if anybody is going to follow their *recommendation*.
It's not like their recommendations have much legal weight, remember
the OSI protocols ? Remember the Modem Wars ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP sinc
t is inappropriate to require that a time
>represented as seconds since the Epoch precisely represent the number of
>seconds between the referenced time and the Epoch."
That made a lot of sense at the time: Operators would have had to
manually update systems to know about the leap sec
roblem" would be quite
>different. time_t uses at least the concept of "day".
No, in fact it doesn't, it just counts seconds, one after the other.
The reason why leapseconds is a problem is that people assume that
it *also* counts minutes, hours and days also.
--
Poul-
Standards should be written for the future, the past
don't care if you change them.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be e
will just feed the UKIP
trolls and become a factor in the Scottish independence referendum.
So exactly how do you propose to sell this idea ?
Remember, the your "competition", changing the definition of UTC
without retaining the name does not require any laws to be changed.
--
Poul-Henning
ware, the POSIX time_t does not do that.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained
quot; according to the parents wishes.
And then came the kicker: One of the older nurses gravely pointed
out that it *was* important to get it *exactly right*, otherwise
the newborn couldn't rely on his horoscope.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | T
:
Number of computers with correct clocks pretty much follows the
fraction of computers running something better than Win98 and
connected to the net by non-dial-up means.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
ooth function of time in
most countries.
UTC was standardized exactly in order to get these legislators out
of international phone bills.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
In message , Richard
Clark writes:
>I've always liked the view that the first century spanned the years 1-99.
Yes, the appeal is obvious, apart from that pescy detail of "century"
meaning "hundred"...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@
g about this subject from what I'd call trustworthy sources.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be
Anno Domini" convention was put into tradition,
it would only make sense for them to talk about the year before and
the year after. Nobody would have any reason to put a zero in there,
If they had tried to do so, it would give no meaning to them, because
"year zero" would literall
In message <52d5cb82.1050...@cox.net>, Greg Hennessy writes:
>On 01/14/2014 06:29 PM, Poul-Henning Kamp wrote:
>
>> It follows rather trivially from the fact that there were no
>> year zero, that the first century must contain the years [1...100] in
>> order to
ernments who can mess with their timezones as they
see fit.
Also, what Warner and I have proposed is that it *might* be
possible to make leap-seconds less damaging by announcing
them 10 years in advance, rather than a fraction of a year
ahead of time.
But the changing-reality-thingie ?
Nope, havn&#x
years [N*100-99, N*100]
Consequently the 20th century must be the years [1901...2000]
Q.E.D.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adeq
In message <20140114150535.ga4...@ucolick.org>, Steve Allen writes:
>These international agencies with multi-letter-acronym names are
>still not listening to each other about the nitty gritty details.
... said the man from UCO/LO(ISB) :-)
--
Poul-Henning Kamp | UNIX sinc
to any particular lump of orbital debris.
In particular not in deference to lack of imagination on the part
of scientist two centuries ago.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Nev
In message <20140114103334.gv21...@fysh.org>, Zefram writes:
>Poul-Henning Kamp wrote:
>>They chose UTC because they meant UTC.
>...
>>The reason why they didn't cater to leap-seconds ?
>>
>>They hadn't heard about them at the time.
>
>It's
special purpose navigation service for the U.S. Navy.
And this timeline may also provide clues, if somebody sift it:
http://www.loran-history.info/LORAN_Implementation_Planning_Installation_and_Termination/1950-1959/1950_1959.htm
--
Poul-Henning Kamp | UNIX since Zi
tamps on the X.25 lines, and we just slaved to those, trusting
that if it was good enough for telcos, we'd be clear also.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to m
chive I might be able
to find it. He's also still alive so he can be asked, but his
eyesight is very very bad, and I doubt he reads emails any more.
(Dave Mills was intimately involved in Loran-C, and he's the brain
behind the 16-pulse "tactical" Loran-C during the vietnam war.)
and protocols for handling traffic and time on
international telegraph, telephone and radiotelephone connections.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to mali
ation, was to make it
possible to precisely schedule and bill international tele-traffic.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explaine
In message <52d2fe51.40...@cox.net>, Greg Hennessy writes:
>On 01/12/2014 02:47 AM, Poul-Henning Kamp wrote:
>> In message <52d20beb.60...@edlmax.com>, Brooks Harris writes:
>>
>>
>>> Yes, in my opinion its unfortunate they chose to use the term "
;inside" UTC didn't mater to them, UTC was the accepted
international timescale and they used it as such.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what c
101 - 200 of 816 matches
Mail list logo
