re is a connection either. When did LORAN-C adopt 1958?
They didn't adopt it, they chose it as a design value. Not sure when.
--
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 attr
nds prior to 1985 was Dave Mills.
--
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.
__
mate agreement with 0 hours UT2
>January 1, 1958.
I'm not sure if there is a connection, and if there is, which way
it might go, but that is also the (theoretical) time of coincidence
of all LORAN-C chains.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org |
pping leapseconds will only cause approx 0.5% more frequent
adjustments to that constant than the previous century has seen.
--
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 attri
same factor, at the same time as leap-seconds took a break.
The rest is (also) history.
But time_t has always been UTC, because it was meant to be UTC.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4
In message <140849.aa05...@ivan.harhan.org>, Michael Spacefalcon writes:
>With all the discussion about POSIX time again, I present for contrast
>how time_t is defined on Non-POSIX UNIX systems. Here is the man page:
... from Michaels Private Unix.
Don't feed the troll.
in "civilized" countries
any more.
There's an interesting moral question embedded in the fact that
certain western countries are trying very hard to prevent the
remaining countries from dropping lead in gasoline, but I suspect
it's really just a matter of money.
--
Po
from our diet.
And don't even get me started about television and a thought-paralysing
means of mass-subduction.
In an ideal world, run by people who all have the surname "phd",
this crap would not have happened.
But then again, in all likelyhood neither would a lot of other s
be even willing
to entertain any but two extreme positions, it seems very likely
that the officers sentiment is spot on.
I think there is a remote chance that if the LEAPSECS audienc decided
to push for such a compromise solution, we might be able to push it
through ITU, but it would requi
ystem for at least one part of the nuclear triad, are pushing the
cheapest and simplest solution they can find: "Drop leap seconds".
The only people identified which really care abut DUT1 are people
who point telescopes and dishes at extraterrstial objects.
--
Poul-Henning Kamp |
dead end, but then I would (might?) learn something.
You mean these people ?
http://www.antipope.org/charlie/blog-static/2013/12/metaphor-for-the-day.html
And yes, those are "my crowd" and Charlie Stross is spot on about them.
So, yeah, good luck with that...
--
Poul-Henning K
ion too effect
in Denmark, and the average frequency dropped by 0.05Hz because they
could save fuel that way. Since then the frequency has just wandered
aimlessly around 50Hz, leaving the phase to do a random walk.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/
ay and
gained them back during the night, similarly they lost half a minute
over winter and gained it back over summer.
After deregulation nobody gets paid to keep the long term frequency,
so mains is no good, actually down-right bad, for timekeeping anymore.
--
Poul-Henning Kamp | UNIX since
half of
the 19-hundredes, timezones were never a reason for it.
UTC was standardized so that telephone, telegraph and radio operators
would not have to keep track of local politics all over the world in
order to operate.
In practice, the "olsen" database is a post-facto recording of
political w
uot;new-fangled" then obviously somebody "fangled"
it, and that person must by necessity be a "fangler".
--
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 att
lished
>>
>> http://www.itu.int/oth/R0A0E96/en
>>
>> As Mike Meyers used to say "Talk amongst yourselves".
>
>The Japanese presentation is genuinely deranged.
And you totally missed, purely by accident I pressume, the bit about
leap-seconds happening
a large-ish computing installation.
A few days ago I received the final production schedule with the
now unchangeable service windows, for the period of 2014-01-01 to
2014-12-31.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
on must be reduced
vastly, or leapseconds must go, because the benefit they provide
is utterly marginal.
--
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
In message , Warner Losh
writes:
>Three things: (1) Leap seconds are rarely done correctly, and even
>when done correctly come at a cost that is disproportionate to their
>value.
I think the CCTF minutes quoted 400k$+ for JPL...
--
Poul-Henning Kamp | UNIX since Zilog Ze
trol
our timescales.
--
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.
___
LE
her words: Just like Einstein proved Newtons mechanics wrong.
It's called "Scientific Progress".
You should try it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
an unfortunate event happening [...]
Or, more likely, ITU changes their regulations to be consistent,
and you can stop breathing into the paperbag...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-
aking their own regulations self-inconsistent.
Grasping at straws, are we ?
--
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
y run PTP, so what ?
The news is that they're willing to assume their data-centers are
synchronized to five digits, not how they do it.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Ne
of the sharpest minds out there when it comes to proper use of
statistics, and he has the track record to prove it.
--
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 wha
Tamino has an interesting analysis here:
http://tamino.wordpress.com/2012/11/03/unnatural-catastrophes/
His quadratic fit of "geophysical catastrophes" peaks duing the
abnormally long dec98-dec05 leap second interval.
Gentlemen, please start your speculations...
--
Poul-He
In message <277995ca-44d0-4b43-8cba-d8f87fe02...@dotat.at>, Tony Finch writes:
>On 9 Jul 2012, at 18:30, "Poul-Henning Kamp" wrote:
>DST exists because people care more about the time of sunrise than the time of
>noon.
Sunset actually, but yes.
--
Poul-Henning Kamp
In message , Rob Seaman writes:
>On Jul 9, 2012, at 8:24 AM, Poul-Henning Kamp wrote:
>
>> In message <46d53f0b-bf98-46c0-a485-4a1494e2c...@noao.edu>, Rob Seaman
>> writes:
>>
>>> More deeply engrained yet is the simple fact that "day" on any
>
In message <46d53f0b-bf98-46c0-a485-4a1494e2c...@noao.edu>, Rob Seaman writes:
>More deeply engrained yet is the simple fact that "day" on any
>planet, dwarf planet, or (spheroidal) moon means the synodic day.
Yes +/- 4 hours or so.
--
Poul-Henning Kamp | UNIX s
t; tab
> for the respective server in the administration interface.
>
> Please do not hesitate to contact us, should you have any
> queries.
>
> Kind regards,
>
> Hetzner Online AG
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP si
t really "spin-locks", I belive it is the kernel the basis for
the pthread mutex in Linux.
>The 5th bug is still a mystery.
No, not really: It's because time doesn't advance a full second for
a full seconds.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@f
l grid (assuming it is on the grid)? Is the plot
>smoothed in any way?
It's only 135 kW, not really a big deal for a data-center, much
less of a deal for the power-grid.
>I don't suppose this particular datacenter is used by Amadeus? :-)
Well, Kristian Köhntopp works for booki
I'm told that this is the power usage from one of Hetzner's datacenters
over the leap-second:
http://imgur.com/a/ykoup
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
timekeeping because they adjust for these leap 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 attribute to malice what can adequately be explain
By far the strangest report I have had is this:
https://twitter.com/tobez/statuses/219228190068064260
Tobez is a friend of mine, so I will quiz him about this.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
In addition to keeping track of my NTP servers I did some screen-grabbing
on Twitter:
http://phk.freebsd.dk/hacks/leap_20120630/index.html
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
... Linux!
or at least some variants thereof:
https://twitter.com/mikko/status/219176755481673729
http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-today
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP
http://xkcd.com/1061/
--
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 , Markus Kuhn writes:
>"Poul-Henning Kamp" wrote on 2012-05-07 12:39 UTC:
>> I suspect that a USRP should be able to do the job ?
>
>A cheaper solution was
Well, neither supports playback...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@fre
I have access to a spectrum
>analyser that works in the band, but its memory is probably too
My idea would be at least two hours of L1, suitable to playback
later on...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
Are anybody are working on making a spectrum recording of GPS signals
around the leapsecond, for use as test-stimuli for testing leap-second
handling ?
I suspect that a USRP should be able to do the job ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP
that the controlling
document were an ISO standard, but couldn't tell me which one...
I wouldn't be surprised if UN has some kind of rule about which
calendar to use to schedule and call meetings, and whatever that
document says, would have a very credible claim to being "it".
--
Po
T REF to get a zero.
--
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.
___
LE
plenty of room for a journalist or spokesman
to get confused about minor details like 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 adequate
Prof. Dave Mills.
>
>I've also heard it from different people in the timing community.
>Usually not in glowing terms. In some cases, I thought they were
>joking about how bad US government bureaucracy can get...
Dave Mills characterization of this split authority was not charita
In message <20120324205441.ga9...@ucolick.org>, Steve Allen writes:
>There is also the interesting assertion that in the US the NBS was
>responsible for frequency and USNO was responsible for time.
I have heard that stated also by Prof. Dave Mills.
--
Poul-Henning Kamp | UNIX
plication where it would make
a difference ?
--
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
sion was monumental.
If you really want fun, name your server "localhost" ;-)
>The data type is more properly termed IEEE floating point. How
>about "float" time? You could tag it with a life preserver logo.
I really don't think the name is as important as the sema
In message <20120125174437.gb12...@lake.fysh.org>, Zefram writes:
>Rob Seaman wrote:
>>Might I suggest that "real" is a poor descriptor here (no philosophy
>>intended)?
The name refers to the data type.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p.
r.
Apart from this confusion, I have yet to see any serious objections
to my proposal ?
--
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
00Z} = {88y}
... but we don't know how many seconds.
Ohh, and btw: That function is a hell to write and it will never
qualify as efficient...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-
In message <4f1e04b4.972.1d564...@dan.tobias.name>, "Daniel R. Tobias" writes:
>On 22 Jan 2012 at 0:09, Poul-Henning Kamp wrote:
>> But you can only convert that UTC timestamp to a realtime_t (and
>> vice-versa) for timestamps where the conversion is defined.
>
away with realtime_t at great
computational expense.
>If you're writing a time library that won't work with an Arduino that
>too is a warning sign.
I fully agree with you, but this is an issue for later.
If we cannot make an API that works correctly when we have enough
CPU-power, we
fail if we don't have a leapsecond table valid for
both timestamps.
--
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 wh
n report an error
>message is not quite right. There are some alternatives:
>
>1) Ignore leap seconds when converting future EST/EDT/UTC-specified
>moments into a timestamp.
ENOCANDO, if we define a new API to deal with leap-seconds, it has
to deal with leap-seconds correctly.
--
on"
See previous discussion about multi-radix formats.
--
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 , "Josep
h S. Myers" writes:
>On Sat, 21 Jan 2012, Poul-Henning Kamp wrote:
>For compatibility with existing binaries [...]
Lets leave that for later.
Right now I want us to come up with a API design which handles
time correctly.
Once we have that in place, we can
In message
, Keith Winstein writes:
>On Sat, Jan 21, 2012 at 7:44 AM, Poul-Henning Kamp wrote:
>
>> libc will need an updated table of leap-seconds to give you UTC,
>> and if you hand it a timestamp that is more than some set delta-T
>> from the last entry in the leapseco
In message <20120121215737.ga17...@lake.fysh.org>, Zefram writes:
>Poul-Henning Kamp wrote:
>struct timeval and struct timespec have an obvious benefit: durations that
>are short decimal fractions of the second can be represented exactly.
The reason for timeval using microseconds
In message <4f1b223c.30...@yahoo.com>, Michael Deckers writes:
>
> On 2012-01-21 18:58, Poul-Henning Kamp asked:
>
>> Why on earth would you even want to specify a difftime ?
>
> Because it is required by standard C?
This is not a current standard C interface, thi
ave bogo-types like
timeval, and avoiding such messes is exactly why I want the
FP in the first place.
--
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
In message , Rob Seaman writes:
>Timestamps are preserved in various data structures for instance
>as identifiers. Two such may need to be compared.
If so, whoever uses it as an indentifier had better make sure he
saves all 128 bits ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus
ting for programming errors.
--
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
why I added the "run_time()" version also.
> Comparing IEEE floating point values holds its surprises
> because values may be incomparable,
In which case they are not valid timestamps, and you get
EINVAL if in a library or whatever you asked for in your
own code.
--
Poul-Hennin
grammers
to do things right, than for them to make mistakes.
But it does solve the problem that you cannot ask the operating system
what time it is.
--
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 <7abcfe74-4bcc-40bf-8421-b0868a6c3...@noao.edu>, Rob Seaman writes:
>Poul-Henning Kamp wrote:
>
>> First of all, I'm not particular wild about floating point numbers,
>
>Then others will feel the same way and will always immediately
>cast the retur
in seconds */
char*tm_zone; /* timezone abbreviation */
};
--
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 a
urns the difference TAI-UTC,
>including the rubber-seconds era.
Ohh, absolutely, there needs to be a bunch of well thought out
convenience functions on top of this.
What I focused on here was solving the show-stopper problems:
1. Getting a sensible algebraic representation of time.
2. Gettin
give you a potentially wrong timestamp.
NTP can transfer the leap-second table these days, and all sorts
of software update mechanisms could as well.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committ
s they are the building blocks
>for everything else.
Exactly.
>Finally, I do think that if its called TAI, then it should use the TAI
>epoch.
No, to aid finding programmer bugs, it should use an epoch that will
generate large errors if^H^Hwhen programmers make mistakes.
--
Poul-Henning Ka
itecture machines
> is 2^-52 =B5s =3D~ 0.2 zs, which is 3 orders of magnitude
> below your proposal.
112 bits still leave us good room.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tah
;, Gerard Ashton writes:
>For the smallest time resolution required, [...]
>The time for light to travel this distance is about 3 as, or about 2^-58 s.
That still leaves 54 bits of integer seconds using the binary128 format,
that should be plenty for the forseeable past and future.
--
Po
eady uses TAI
TAI can be derived from UTC, GPS and other broadcast timescales, so
availability is fine.
--
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 ad
query of
>seconds to have to handle leapsecs, which is undesirable for API
>usability).
Remember, this may not be the API the user sees, there would very
likely be an intermediate level of "convenience" functions. What
I am trying to describe is the _lowest level_ of timekeeping serv
http://geneva.usmission.gov/2012/01/20/statement-on-the-leap-second-and-future-of-the-universal-coordinated-time-utc/
--
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
LT)
The struct tm is not a valid timestamp on the specified timecale
(errno = EINVAL)
The struct tm is outside the validity of the timescale translations available
to the program (errno = E2BIG)
The tz parameter describes a unknown or unsupported timescale (errno = ENOENT)
All implementations must sup
have gotten terribly drunk if ITU had abolished
leap seconds on my birthday :-)
--
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 a
; probably doesn't help.
--
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.
_
delegates are almost entirely broadcast and telco industry people.
Can we even find one single qualified time-nut in Geneva if we try ?
--
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
ee any of these rumours being sourced or credidble.
So: no.
--
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 ad
http://www.youtube.com/watch?v=Px6nS80SdkE
--
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
inactive.
That would in my mind be a pretty perverse way to interpret the text,
and I seriously doubt that anybody with just a marginal perception of
the subject matter would interpret it that way.
That of course still leaves 95% of all programmers and 99.99% of
all journalists subject to confusion
How many factual errors can you spot ?
http://www.canada.com/Leap+second+have+only+hours+live/6015224/story.html
--
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
In message <20120118122617.gc56...@davros.org>, "Clive D.W. Feather" writes:
>Poul-Henning Kamp said:
>>
>> Here is a nut-cracker much better than a Danglish split infinitive:
>>
>> http://www.agile-news.com/news-560573-Time-who-will-vote-on-the-side.ht
In message <719683fad725c87fb7cb156e7eabdb7a.squir...@mx.pipe.nl>, "Nero Imhard
" writes:
>Poul-Henning Kamp wrote:
>
>> With respect to national laws, they are N times easier to fix than
>> an international treaty, and therefore much less of a concern.
>
>
In message <4f1648dd.31240.23276...@dan.tobias.name>, "Daniel R. Tobias" writes
:
>On 17 Jan 2012 at 20:59, Poul-Henning Kamp wrote:
>
>> A lot of technical treaties and regulations say UTC in no uncertain words,
>> for instance in air-space regulations. I am
7 would give a lot of interesting issues where ATC facilities are
time synchronized to the new scale, but should have been to the UTC scale.
I can't imagine any delegate to the ITU being stupid enough to put his
name on that idea.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@
was the first time any *nix kernel had touched its timekeeping
code in ten years, and first time in 20 years any of them had
improved on it. This is also why he insisted we co-author a paper
on the subject (I delivered the data and graphs, he wrote the text :-)
--
Poul-Henning Kamp | UNIX si
s.
WG7, unable to reach consensus, have sent the proposal upstairs
to the general assemblyy
ITU have just moved the documents around and charged for the
croissants...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer
bout the US government, don't complain about ITU.
--
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 adequ
Here is a nut-cracker much better than a Danglish split infinitive:
http://www.agile-news.com/news-560573-Time-who-will-vote-on-the-side.html
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
tion is stylistic or
>prescriptive, "These conditions will make the future interpretation
>of the now polysemous term impossible to unambiguously determine
>in many circumstances." is pretty horrid.
That's not a split infinitive, that is Danglish :-)
--
Poul-Henning Kamp |
"?
>Or is it an all-or-nothing deal?
It would require a lot of editorial work in a LOT of international
documents (rules for shipping hazardous goods, rules for passenger
planes, rules for telecom traffic accounting etc) not to mention
to laws in a number of countries.
--
Poul-Henning Kam
ess.
--
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
ey can
define UTC without leapseconds, if they can agree and coordinate to
do so.
Now, please stop the whining.
--
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 a
"time IS earth orientation" argument
is equally unpersuasive for others.
--
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
In message <7422cd7e-2405-4c94-99d6-b9da1f1bc...@pipe.nl>, Nero Imhard writes:
>On 2012-01-09, at 20:42, Poul-Henning Kamp wrote:
>
>> It can easily be argued that if you need UT to better than 1s, you
>> should use one of IERS's UT products and you will have five year
ne of IERS's UT products and you will have five years to
make the fix.
--
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 <43660828-da25-44ed-9c97-8afc511c0...@noao.edu>, Rob Seaman writes:
>And it will leave any purely atomic timescale many minutes or hours
>in error at a future epoch with no plan for mitigation.
Try to be precise: " no plan *OR DESIRE* for mitigation."
In message <4f09e68b.20191.5827...@dan.tobias.name>, "Daniel R. Tobias" writes:
>On 8 Jan 2012 at 17:10, Poul-Henning Kamp wrote:
>
>> I have taken the liberty of alerting Hanne to the fact that you may
>> try to harness her to a political wagon and that it migh
201 - 300 of 816 matches
Mail list logo
