Next Chapter In the Leap Second Story

at10u8 writes "The ITU-R and BIPM are holding a joint workshop on the Future of the International Time Scale. This is the next of many steps toward the possibility that radio broadcasts of time signals might abandon leap seconds. All of the presentations are online and the press release for the workshop indicates there will be video interviews afterwards."

Comments

articles by the workshop participants

[at10u8]

The ITU has also put up an issue of ITU News with in depth articles.

Double time

[Anonymous Coward]

So... err... how will it go now? Instead of posting a 60th second they will make the 59th second twice as long, and have everyone think their clocks are fast, accept that out of sync clocks are a fact of life, and just synchronize?

Re:Double time

[presidenteloco]

I think they plan to speed up the Earth's rotation so that the computer clocks will stay synchronized with daylight.

Re:Double time

[aardvarkjoe]

So... err... how will it go now? Instead of posting a 60th second they will make the 59th second twice as long, and have everyone think their clocks are fast, accept that out of sync clocks are a fact of life, and just synchronize?

They'll simply stop trying to correct UTC to match the rotation angle of the earth. "Correcting" UTC that way is mostly helpful to astronomers, and for everyone else has no benefit and some significant drawbacks.

Re:Double time

[msauve]

Civil time has always been based on the sun. For anyone who doesn't like dealing with leap seconds, there are well established alternate timescales available which don't use them, such as GPS and TAI. There is no good reason to eliminate leap seconds from UTC, which was very specifically developed to closely track the earth's rotation, like its other UTx siblings. The people who want to eliminate leap seconds from UTC are the ones who chose their timescale poorly, and now want those who use it properly to suffer for their mistakes.

There's good coverage here.

Re:Double time

[msauve]

missing link

Re:Double time

[cjameshuff]

It's not even helpful to astronomers. Your telescope's direction will jump by 15 arcseconds for every leap second applied. If you want precise pointing, you'll use a rotation model based on more detailed data on Earth's rotation with a timebase that's actually real time, not some mostly-increasing number with arbitrary jumps forward and back.

Re:Double time

[evanh]

"Everyone else" doesn't much care either way. I think you'll find it's just as few people that think it shouldn't be a moving target.

I don't see why leap seconds has ever been an issue. Date-stamping has always been a fickle mechanism that always shifts around according to whatever governments decide.

Metronomic sampling on the other hand doesn't give a shit about the calender and only cares about regular timing.

The two systems, sampling and date-stamping, should not be confused and the one should not dictate to the other. Both can and should be provided for side by side.

Re:Double time

[Greyfox]

Except no one seems to know the difference, and it's literally impossible to know an accurate time in a system involving more than one component. Accidentally make the adjustment twice and you're in as bad shape as if you hadn't made it in the first place. I E-mailed a developer about a piece of a spec that didn't specify and asked him if the time was GMT or UTC. His response was "What's the difference?" Not something you want to here from someone who maintains astronomical software. Other parts of the spec said "UTC" but they meant UTC in the POSIX sense of the word, without leap-seconds. Which isn't really UTC, now, is it?

There are better ways to achieve the same goal. Just publish the second-offset and make your adjustment explicitly when you have to. Then when someone comes along who has to maintain your system, they'll actually be able to tell.

As an aside, part of the leap-second resolution should involve finding the member of the POSIX committee responsible for that part of the POSIX spec and punching them in the forehead :-/

Re:Double time

[Forever Wondering]

Perhaps it's time to go the other way and use GPS/TAI for computer clocks instead of UTC. In other words, perhaps civil time should be changed. Just because it used to be based on something doesn't mean it needs to be in the future.

Leap second adjustments at the time that they occur are problematic for OS scheduling during that period. Also, you have to maintain a table of whether the twice a year leap second has been applied [and in which direction]. The table must be updated every six months because a table entry can't be predicted beforehand [because it's decided upon by IERS]. The application of leap seconds is actually quite irregular.

All this complexity for a [possible] adjustment of one second every six months?

Alternative schemes have been proposed that would accumulate leap second error until it truly becomes significant (e.g. do a leap minute adjustment every thirty years).

If the timebase that we use in the modern world (e.g. computers, cell phones, banking transactions, etc.) needs to track the sun that accurately, why do we tolerate error accumulation of up to a day every four years [leap days]?

Re:Double time

[rk]

Because the leap year doesn't have anything to do with time of day, but the position of the earth regarding its axial tilt in its orbit. If we quit using leap year days, noon would still be more or less noon every day but the seasons would start marching forward in the calendar and spring would start in April, then May...

Re:Double time

[rk]

This. If you don't want leap seconds and don't care if you're synchronized to the sun, you already have two timebases to choose from. Do this and you take away a use case from others, and then have THREE to choose from.

Re:Double time

[msauve]

It's perfectly reasonable to ask that legal systems change to something other than UTC, if avoiding leap seconds in civil time is beneficial.

Leap seconds can occur in any month, there's simply a preference that they occur the end of June or December. But, worldwide, there are more significant adjustments to be made, on a more random basis, due to meddling with time zone offsets and summertime dates.

Leap second adjustments at the time that they occur are problematic for OS scheduling during that period.

Huh? Leap seconds are announced well in advance. The enumeration is well defined. Any scheduling problem is due to poor code, which expects every minute to have 60 seconds, every hour to have 3600 seconds, etc. Leap seconds have existed for over 40 years, so there's simply no excuse for code so sloppy it can't handle them.

If the timebase that we use in the modern world (e.g. computers, cell phones, banking transactions, etc.) needs to track the sun that accurately, why do we tolerate error accumulation of up to a day every four years [leap days]?

You're confusing the rotation of the earth, which affects time of day, with the earth's orbital period, which has more effect on seasons (although not exactly, due to precession).

Re:Double time

[Forever Wondering]

Leap seconds are problematic not because of sloppy coding but because they are a messy problem.

During the one second interval when they are applied, what happens to [UTC] timestamps on files that are modified? If you're compiling, an object file may be updated or not. Or, with rsync, a file may be transferred or not. Or, what about medical equipment [based on POSIX-compliant UTC (e.g. Linux, etc.)] that gives a patient an extra one second of radiation because the master clock is based on UTC?

Also, applications [which generally don't account for leap seconds] would get lurched, sometimes with disastrous results.

That's why Google came up with a "leap smear": http://www.theregister.co.uk/2011/09/19/google_has_to_lie_to_computers_about_time/

The solution we came up with came to be known as the 'leap smear'. We modified our internal Network Time Protocol [NTP] servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens. This meant that when it became time to add an extra second at midnight, our clocks had already taken this into account, by skewing the time over the course of the day. All of our servers were then able to continue as normal with the new year, blissfully unaware that a leap second had just occurred.

I confused nothing [re. leap days]. That was just a loose analogy. Nobody would notice if we applied leap seconds or not. Not even a leap minute every fifteen years would be noticed. And that's the maximum error you can have. Nobody will care if the sun sets in the west a minute earlier than you expect it to [based on TAI]. Better yet, since we tolerate daylight savings time, wait until the leap second error hits an hour. That will take 900 years minimum.

Since July 2012, IIRC, all corrections are now formally set at six month intervals. While most corrections have been in one direction, if we just kept track of the error, it might self correct over a long enough period.

Converting all systems (computers, cell phones, NTP, etc.) to use TAI internally would be a good thing. Convert to UTC when displaying the time [could be a user preference]. Everything becomes simpler and more accurate.

Those that truly need to track solar time are a minority (e.g. astronomers, etc.). Let them do the extra conversion rather than burdening the rest of the world [and the systems we use in our daily hitech/21st century lives].

Re:Double time

[Pinky's Brain]

"During the one second interval when they are applied, what happens to [UTC] timestamps on files that are modified? If you're compiling, an object file may be updated or not. Or, with rsync, a file may be transferred or not."

Only with negative leapseconds, which have never been used ... as long as the timebase is monotonic these shouldn't fuck up. As for POSIX using a timebase which might not be always monotonic for file timestamps ... well that is sloppy coding. The sloppy coding being part of POSIX is no excuse.

"Or, what about medical equipment [based on POSIX-compliant UTC (e.g. Linux, etc.)] that gives a patient an extra one second of radiation because the master clock is based on UTC?

Also, applications [which generally don't account for leap seconds] would get lurched, sometimes with disastrous results."

Yes, as he said ... sloppy coding.

Re:Double time

[Anonymous Coward]

Civil time ceased being based on the sun when time zones were invented starting during the late 1800's. For most people in the world now there is a huge discrepancy between solar noon and noon, civil time. For example, what are the local civil times for your sunrise and sunset this Sunday, the September Equinox?

Re:Double time

[msauve]

During the one second interval when they are applied, what happens to [UTC] timestamps on files that are modified?

Whoosh.

You're not describing a problem, you are the problem. If an event occurs during a leap second, you simply timestamp the time, 23:59:60.x. What you describe simply demonstrates the problem with incorrect assumptions and sloppy coding: that a minute can't have more than 60 seconds. That hasn't been the case for over 40 years.

based on POSIX-compliant UTC

'taint no such thing. There's UTC, and there's POSIX, which is in no way compatible with UTC, which existed long before POSIX. Just another example of brain-dead, incorrect assumptions about timescales.

Since July 2012, IIRC, all corrections are now formally set at six month intervals.

YRI. You should at least try to understand the subject you're discussing.

"A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September.
- ITU-R TF.460-6.

Re:Double time

[bondsbw]

I'm going to try this in Kerbal Space Program. If it works, I'll let NASA know.

Re:Double time

[FatdogHaiku]

I think they plan to speed up the Earth's rotation so that the computer clocks will stay synchronized with daylight.

But the bad news is we all have to get out and push!
Personally I think if they legalize weed no one would worry about a second here or there...

Re:Double time

[Anonymous Coward]

GMT is not a time, it's an offset specification for UTC+0. So his response was basically correct even if a bit ignorant sounding.

POSIX does have leap-seconds, and is UTC. I think you are mistaking POSIX (UTC) with the time returned by GPS receivers which is incorrectly labelled UTC in NMEA0183, while in fact being UT1 (counting in slewed seconds to correct for meridian drift). TAI is time measured in seconds without meridian drift correction.

They probably should have defined posix seconds to be measured in TAI (which would be confusing to people who don't know about meridian drift) or UT1 (which would be confusing to scientists expecting 1 posix second to actually be 1 second by SI standard). Then the seconds to broken down time like gmtime, localtime could be implemented by table lookup to find the current meridian drift offset. The choice they made was the most complex and hardest to implement option of the available choices, and by my opinion the wrong one.

Re:Double time

[Anonymous Coward]

Or, what about medical equipment [based on POSIX-compliant UTC (e.g. Linux, etc.)] that gives a patient an extra one second of radiation because the master clock is based on UTC?

I shudder to think anyone is using Linux POSIX timers to dose radiation, since they provide no maximum lateness guarantees, I have seen clock_nanosleep be 15 seconds late on a 5 seconds timer under heavy load.

On a realtime POSIX system that provides strict lateness guarantees, perhaps Ingo Molnar's Linux-rt or WindRiver's RTLinux, though I have seen lateness bugs while using Ingo's Linux-rt patches, you should be using CLOCK_MONOTONIC for all timers where the interval is critical. If you're using CLOCK_REALTIME, which is the default for sleep and usleep for interval timing, you're an idiot and you shouldn't be programming medical devices (which would make you a dangerous idiot).

You should always use CLOCK_MONOTONIC for interval timers and CLOCK_REALTIME for deadline timers.

Re:Double time

[AmiMoJo]

Most people don't have a choice, they have to work with some protocol that chose UTC without really understanding the issues many years ago.

Re:Double time

[Forever Wondering]

During the one second interval when they are applied, what happens to [UTC] timestamps on files that are modified?

Whoosh.

Whoosh yourself ...

You're not describing a problem, you are the problem. If an event occurs during a leap second, you simply timestamp the time, 23:59:60.x.

Yes, that's what the spec talks about. But, it isn't how times are represented internally in systems. They use binary [64 bit] numbers that are [usually] offsets from Jan 1, 1970 [the Unix epoch]--except for MS, of course.

It's what happens to a [normally] monotonic sequence: n,n+1,n+2 when you present n,n,n+1 or n,n+2,n+3 instead at the binary level and how you handle the discontinuities [if you're even in a position to know the discontinuity has occurred]. Most software just sees any and all of the above as k,k+1,k+2 so it has no way to compensate. In most cases, it can't because the leap second insertion is done in such a way (at the NTP server) that it is invisible even to the OS, let along a userspace program. The user program would have to know the internal OS policy [which it usually doesn't].

Some programs don't care what n/k is [it could be 31579 or 0] because they're more interested in a time delta across a [very] short interval. Leap seconds wreak havoc with that. That's why Google came up with its "leap smear" solution.

Really, your description of how you timestamp a file shows complete ignorance of how OS's, filesystems, processes actually handle these problems.

And that you're not a programmer. I am. In the kernel/driver/realtime arena for forty years. I deal with keeping systems synchronized at the nanosecond level all the time. So, please stop preaching to the choir.

What you describe simply demonstrates the problem with incorrect assumptions and sloppy coding: that a minute can't have more than 60 seconds. That hasn't been the case for over 40 years.

The assumptions weren't incorrect. They were just ones you weren't aware of [see above]. Your [repeated] use of "sloppy coding" sounds like armchair quarterbacking. Have you analyzed the cost/benefit across a wide range of applications and the risk associated with trying to apply a fix that may have little to no benefit? For example, which programs and what remedy should be applied?

based on POSIX-compliant UTC

'taint no such thing. There's UTC, and there's POSIX, which is in no way compatible with UTC, which existed long before POSIX.

If I had said "POSIX-compliant [use of] UTC" instead, you'd have nothing to argue about.

And leap seconds were not part of the original UTC spec. The folks that added the leap seconds [however well intentioned] didn't anticipate the complications to existing systems already using UTC (e.g. Unix which predated leap seconds by a few years). Now, many are questioning their [marginal] utility versus the complexity they [still] engender [particularly for realtime systems, such as video broadcast], which is why the discussions are going on about removing them from UTC.

Just another example of brain-dead, incorrect assumptions about timescales.

I've also worked on commercial grade realtime video broadcast systems, where I've had to coordinate 5-6 timescales at one time. So, my friend, what's your specific expertise that justifies the invectives?

Since July 2012, IIRC, all corrections are now formally set at six month intervals.

YRI. You should at least try to understand the subject you're discussing.

"A positive or negative leap-second should be the last second of a UTC month, but first
preference should be given to the end of December and June, and second preference to the end of
March and September.
-

Re:Double time

[msauve]

Just. Wow. You don't know what "monotonic" means. You don't know what a discontinuity is. You don't know how to do subtraction. You obviously suck at programming. You don't know the difference between a normative standard and an informative statement. No wonder you have problems dealing with relatively simple matters like leap seconds.

Re:Double time

[Megane]

Or, what about medical equipment [based on POSIX-compliant UTC (e.g. Linux, etc.)] that gives a patient an extra one second of radiation because the master clock is based on UTC?

You know a radialogist who works at 2AM on Sunday?

Re:Double time

[Megane]

Grrr... I realized as I clicked the button that leap seconds happen at midnight. But still, you know a radiologist who works at midnight? People aren't just left sleeping in that kind of medical equipment with no operator. Also, if someone is basing elapsed time (of less than an hour or so) by subtracting two time readings (rather than using a millisecond uptime timer from the OS), they're an idiot.

Re:Double time

[Anonymous Coward]

Yes,
They're probably looking to contact Superman. They should probably ask him to get rid of all of the nukes after he's done with that. And then there's those pesky extraterrestrials (almost said "aliens" for a second there...) that he could deal with.

This sounds like movie material to me...

Re:Double time

[Anonymous Coward]

At midnight UTC? I don't know any radiologist outside Europe but I'm sure there are plenty.

Re:Double time

[rvw]

I think they plan to speed up the Earth's rotation so that the computer clocks will stay synchronized with daylight.

With GTA V out, we just have to get everyone to drive eastward.

Re:Double time

[Anonymous Coward]

So instead of changing those specific protocols, which affects only those protocols that want to change, we're supposed to change the time base itself, which affects everyone?

Re:Double time

[at10u8]

Look deeper at one of the underlying problems in this issue -- see blockquote in the "UTC in 1982" entry here. That paragraph was written by one of the folks who actually worked in the field of timekeeping, and those are the folks who produced the documents that get approved by the votes. (All the votes by those agencies that make the official documents are done by delegates who know next to nothing about the subject matter.) See how that 1982 paragraph crows about the way that UTC with leap seconds has solved all problems and become accepted by everyone. They were oblivious to the problems that would crop up. The process of making the decisions and producing these international recommendations has not changed much in the subsequent 30 years.

Re:Double time

[Anonymous Coward]

Just alter the gravitational constant of the universe it's easy.

Q

Re:Double time

[Forever Wondering]

Yes. From the blockquote: "constitute a powerful endorsement of the carful work". Guess somebody wasn't carful "E"-nough :-)

The self congratulation aside, they had different goals at that time. They were looking for a unified/legal definition of time that could be universal.

I don't think even many programmers realized the implications at the time either. I mean, Intel was rolling out 5Mhz chips then. The focus was rolling out PC's as a credible alternative to the mainframe world. As the CPU's sped up, the problems became more apparent.

Nice website--thanks.

I found another page on it that has an interesting idea: Set up an ntp stratum 1 server driven by a GPS clock. Don't transmit leap seconds. Adjust the time offset a bit [to compensate for the initial syncup of GPS time with UTC], modify NTP client code, then handle all leap seconds via the zoneinfo data files.

Re:Double time

[Greyfox]

POSIX specifies leap seconds aren't included. POSIX also states that times are UTC. But it SPECIFICALLY says that leap seconds are not included. It doesn't say UT1. It says UTC, no leap seconds. And that's why man with one watch doesn't know what time it is.

Linux mostly follows POSIX but has the ability to include leap seconds if you want them. IIRC, NTP includes leap seconds (Which occasionally breaks both NTP and various OS kernels.)

adjustment

[rossdee]

cant they just do these adjustments when we are scheduled to do the switch to or from daylight saving time since you have to fiddle with the clock anyway

Re:adjustment

[Anonymous Coward]

Different timezones have different policies with regards to daylight saving time, and a lot do not have it at all. This means that although it makes a lot of sense for specific timezones, it doesn't work for a global standard.

Re:adjustment

[Anonymous Coward]

South of the equator, we move *to* DST late in the year, and move off it again early in the NEXT year.
North of the equator, you move to DST early in the year and move off it again late in the same year.

So, no, we don't all move to/from DST at the same time. But we want to have UTC the same world-wide.

Re:adjustment

[complete loony]

They should just stick to one standard frame of reference, similar to GPS time. The translation to local timezones could include leap seconds if you want it to. Conversions to local timezones already has some ambiguity as you mentioned due to daylight saving time. Software developers need to abandon the idea that datetime values in your local timezone can be stored, compared and used in calculations as only a single number.

Re:adjustment

[Anonymous Coward]

No ambiguity in DST if you consider it "time zone hopping". Now you're in GMT+1, at 1am GMT+1 you switch to GMT+2. And later, at 2pm GMT+2 you switch to GMT+1. Tadaaa. Magic :)

I find it stupid to even say "we're in GMT+1, but we have DST on". No, you're in GMT+2 for the half year, and will be GMT+1 for the other half. If you work in local time, it doesn't matter which timezone the timestamp is in. If you work with global time, work with GMT. Even when you work with GMT, you should use a timestamp that incorporates the timezone information (2013-09-20 00:07:00 +0000)

Re:adjustment

[sjames]

For leap seconds I just let NNTP correct it, so it has never been an issue in the first place.

Re:adjustment

[complete loony]

Exactly, which would force you to store every datetime with the relevant timezone instead of assuming all of your datetime values are in the same zone. Which is essentially what I implied.

Re:adjustment

[the_other_chewey]

For leap seconds I just let NNTP correct it, so it has never been an issue in the first place.

Impressive. How did you solve the problem of time dilation due to flame wars?

Re:adjustment

[thegarbz]

Which daylight savings? In what territory of what timezone? When you switch your clocks is not the same when I switch my clocks (hint: never). Not to mention that some clocks change at a different month than others.

So far we need to keep track of timezones and daylight saving time, and even massive companies fail to be able to do this correctly without issue (Apple isn't the only one). Do you now propose we keep track of which subsections of which timezone are a second ahead or behind given the arbitrary application of the leapsecond?

A program now must not only handle a clock that will move forward one hour and back an hour on certain days, but may move forward one hour, back 59:59 at the arbitrary whim of some group.

Re:adjustment

[sjames]

I just wait for the flamers to disappear up their own assholes :-)

Re:adjustment

[jon3k]

God no, don't tie something practical like leap seconds to an arbitrary daylight savings scheme. Just abolish daylight savings.

TAI

[Anonymous Coward]

If someone wants a time reference that doesn't hop around they can use the already existing TAI:

http://en.wikipedia.org/wiki/International_Atomic_Time

UTC has a certain definition, and so does TAI. Leave each as it is and let people do a "TZ=x" however they wish.

Re:TAI

[lgw]

The proposal seems to be a bit of a legal hack. You could switch to TAI for civil purposes, but then many countries would need to amend many laws to say "TAI" where they now say "UTC", and all those legal changes should happen together for sanity, which is a bit impractical. Or, you could just change the definition of "UTC" and then all those countries laws change seamlessly together.

Re:TAI

[sjames]

I suspect iot's more like the law says whatever it does and it's worked well enough so far. The last thing they need is for UTC to be randomly redefined out from under them. I propose we define UTC to be TAI + a randomly selected value between 0 and 3600 (known hereafter as WWTW aka wibbly wobbly timey wimey) just to screw with them.

Re:TAI

[lgw]

Everyone on both sides of the political debate seem to agree that leap seconds are just an annoyance, the division seems to be between "let's do this trick" and "it's not annoying enough to change anything, just leave it be".

I never really understood the motivation for leap seconds myself - it's not all that helpful for pointing a telescope, and for all non-astronomers it's just annoying. Far better to adjust by an hour at one far future point when GMT is "off" by a full hour than to constantly tinker with the clock.

Re:TAI

[sjames]

An adjustment of an hour can be a real annoyance, adjusting by a second is lost in the noise. There are much larger consequences if a closk is off by an hour, practically none if it is off by a second. People who grew up before clocks synchronized by radio or the cell network even expect clocks to be off by more than a second but off by an hour is noteworthy..

Re:TAI

[xenobyte]

An adjustment of an hour can be a real annoyance, adjusting by a second is lost in the noise.

That's why good sysadmins run their systems on UTC, only converting to local time for display purposes. Daylight Savings Time (or summer Time) and its one hour jumps is a huge pain in the butt and people running cron according to local time have to handle jobs being skipped or jobs being run twice. Sure, using UTC the jobs are off by an hour during the summer but that really shouldn't be that much of a problem. Making sure they run and run only once is more important.

Alternatively - useful if you have jobs that need to run on a specific time - you can plan these to avoid placing them in the 02:00-03:00 window where the mess happens, and use local time. They they will run as scheduled even on the switch-over days.

Re:TAI

[Anonymous Coward]

There is an even simpler way to make this problem go away. Add a kernel config option to keep system time in UT1 or TAI, and amend NTP (PTP already has support for monotonic timebases and stepped timebases, and markers for TAI, UT1 UTC timebase references) to support alternate timebases.

Also UTC isn't "not all that helpful for pointing a telecsope", it's TOTALLY USELESS for pointing a telescope, firstly because it steps by 15 arc-seconds and can therefore have an offset of +/-15 arc-seconds at any given time, and secondly because the Earth's orientation is not a simple phase relation to time, but is affected by orbital eccentricity, obliquity, and precession, and so pointing is a complex multi-termed function of time, which is usually given to the steering computer by UT1 from GPS or TAI from an atomic clock.

Re:TAI

[Anonymous Coward]

That's why good operating systems run their systems on UTC, only converting to local time for display purposes

FTFY

Re:TAI

[AmiMoJo]

A lot of industrial devices ignore DST. It's just too much hassle to implement and can break things like schedules. You don't want any unpredictable behaviour in an industrial process or sensor network.

Re:TAI

[sjames]

All the more reason not to throw in another hour to adjust by (or ignore) somewhere.

Re:TAI

[lgw]

Clocks aren't "off" unless they disagree with whatever standard time is. If we remove leap seconds from UTC, then all clocks that don't have leap seconds (you know, like most actual clocks that exist in the world) will keep correct time.

Adjusting by an hour 300 years from now is a small cost.

Re:TAI

[sjames]

Most clocks now DO have a loose tracking of leap seconds. They are either adjusted by NTP silently, are slaved to a clock adjusted by NTP or that is otherwise adjusted, or they are free running but occasionally corrected to match such a clock.

It works so well as it is that many people don't even know leap seconds are a thing but their clocks are right.

Re:TAI

[lgw]

Most clocks still hang on the wall, or sit on an end table, or are worn on the wrist. Though perhaps we'll cross over some time this century to where there are more cell phones than discrete clocks, I guess. Hell, I have 2 clocks in my car, and only one is synced to an external source, which is quite odd twice a year.

It occurs to me that the best time to make the odd adjustment would be years evenly divisible by 400 - instead of a leap day, we'd have a leap hour-or-so. That's the point at which the "adjust timekeeping precisely to the sun" has traditionally happened, after all.

And, again, "right" is "agree with everyone else", not "agreeing with the sun". There's just not point in doing the latter accurately.

Re:TAI

[sjames]

And all of those wall clocks, wrist watches, etc are periodically synced up with cellphone, computer (set by NTP), whatever the TV station says (set by time standard), etc. They are the third type I mentioned. Since they are not expected to be accurate to the second, the periodic adjustment will track close enough over the years. Why make them all suddenly wrong beyond the expected minute or two one fine day in the future?

And yes, WRONG as in clock at home (missed the update) disagrees by an hour with clock at work (did get adjustment) sufficiently to get your ass chewed out.

DST seems to get people's panties in a bunch and that happens regularly enough that everyone knows about it. Throwing in another hour somewhere will create confusion. OTOH, a second here or there doesn't matter to most people.

At the end of the day, for most people, the SUN is right and they expect their clocks to stay roughly in sync with it.

Re:TAI

[at10u8]

Yes "right" is "agree with everyone else", but in the existing documents by which various international agencies approved the use of UTC all of them did so along with an assertion that everyone was agreeing with "mean solar time"; i.e., that days are counted by measuring the rotation of the earth. Those engineers who are free to ignore regulations and statutes can choose to use something like GPS time, but many projects and systems are constrained to conform to existing regulations and do not have that liberty. Any project or system which is constrained to use both UTC and POSIX is SOL every time a leap second happens.
This international regulatory process has repeatedly failed to engage all the stakeholders in an open discussion of what everyone expects and needs. The result of that has been "failure of imagination" when one agency embarks on a course that differs from the existing agreements.

Re:TAI

[lgw]

But this is a debate about what those very statutes should be, not about what some geeks will do. Seriously, who cares about POSIX? The general consensus seems to be "leap seconds are bad", because agreeing with solar time only loosely matters in the first place, and simpler is always better. The argument is over whether it matters enough to change anything.

Re:TAI

[lgw]

The Sun only needs to loosely correlate. If UTC was changed to be 24*3600 seconds per day, period, that would be close enough for decades, even centuries at a time (and if it drifts slow enough, whatever it is it whatever it's been you're whole life).

It's just far simpler to have a system of time that could be kept mechanically, with a "solar correction" every 100 years (which we already do! we skip leap days) . And, really, if we had any kind of vision as a species, why would we care about where the Sun is in the sky on one particular planet in the first place? How provincial.

Re:TAI

[sjames]

Really, how practical. We do not today, nor are we likely within our lifetimes to have a significant number (if any) of humans on any other planet. We do have a significant number of activities that either depend on the sun or work better when scheduled with the sun. Why shouldn't our time track it at least until we actually do have a significant population elsewhere (even then I suspect we'll mostly stick to local time and only use the more universal time when interacting with those other people).

And those 100 year corrections are to keep the months and day of the year consistent with the seasons. Through the leap day every 4 years and the correction every 100, we keep the days of the year within 1 day. That's the best we can do without skewing the hours of the day. Adjusting by 6 hours/year would track closer but then our clocks would really be out of whack compared to the sun, so that's out.

itu website sucks

[Anonymous Coward]

they don't even seem to understand basic concepts like the cooky trail, or having your options up at the top of thepage...sad

It's no problem AT ALL.

[Anonymous Coward]

It's no problem AT ALL. Except it makes the high volume traders trading in co-located offices in the major stock exchanges life a little less pleasant.

Basically, if the leap second comes in on a trading day then your millisecond HTF transaction may not get in as quick as someone else's transaction that isn't located in the same room as the stock exchange and therefore is a fraction of a second slower normally, but because the leap second propogates indeterminatedly on the millisecond scale, they get in "first". This means you haven't shaved 0.0001% of a trillion dollar transaction and therefore you've lost thousands of dollars.

And therefore the cost of selling space to these people by the stock exchanges is less: you can expect less profit from it.

And THAT is the sole reason why this happens: the banks and stock exchanges and biggest traders would like to have no leap seconds for their business needs.

EVERYBODY ELSE can, in their view, go fuck themselves.

Hence why there's EVERY SINGLE FUCKING YEAR the same complaints about

1) Time Zones.
2) Leap Seconds.

No it won't.

[Anonymous Coward]

Your telescope's tracking is based on interval timing, not absolute time.

I.e. "Every 0.390043 seconds, move the WORM drive one step".

It takes longer than 1 second to go from looking at one star to tracking another object and you ALWAYS re-lock on the location.

Moreover, those astronomers require that leap second, otherwise you need to change the RA values every time you otherwise have a leap second.

You're the same no-possible-way-to-be-more-wrong asshole in the other post where you claim:

"Civil time ceased being based on the sun when time zones were invented starting during the late 1800's. "

The reason for those time zones was because the Sun is at a different position of you move quickly enough from one location's noon and keep your watch on your original location's time.

an hour can be importankt

[Anonymous Coward]

http://www.omg-facts.com/Interesting/Three-Suicide-Bombers-Exploded-Premature/53085