Vote To Eliminate Leap Seconds

Mortimer.CA writes "As discussed on Slashdot previously, there is a proposal to remove leap seconds from UTC (nee 'Greenwich' time). It will be put to a vote to ITU member states during 2008, and if 70% agree, the leap second will be eliminated by 2013. There is some debate as to whether this change is a good or bad idea. The proposal calls for a 'leap-hour' in about 600 years, which nobody seems to believe is a good idea. One philosophical point opponents make is that the 'official' time on Earth should match the time of the sun and heavens."

Yup.

[Estanislao Martínez]

I think the problem with this is that the distance between the sun and the earth is not constant.

But that's just the start:

• The time it takes for the Earth to complete one cycle of rotation (i.e., an Earth day) is not constant.
• The time it takes for the Earth to complete one cycle of translation (i.e., an Earth year) is not constant.

How do we know they're not constant? Because we can measure the variation using atomic clocks, of course.

Re:Why not just make each second a little longer?

[mbone]

Of course, the real problem is that the rotation of the Earth is not constant (the leap seconds are mostly driven by fluid motions in the core).

Originally, back in the 1960's, instead of the leap seconds, they (the BIH at the time) adjusted the rate of the UTC seconds with respect to TAI. This was widely viewed as not a good thing once it was tried and was dropped, IIRC in 1972.

Re:They have to add a leap something, sometime

[evanbd]

Leap years are to deal with correcting the length of the year, which isn't an integral number of days. Leap seconds [wikipedia.org] are to deal with the fact that the length of a day changes slowly and at a variable rate. It's not the same problem at all.

Re:Why not just make each second a little longer?

[justinlee37]

we'd stimulate the living hell out of the world's economy.

But that wouldn't stimulate it at all. The opportunity costs would be massive. See the "broken window" fallacy.

Your post - Bollocks

[janrinok]

We used to have 120 pence to the pound in the UK

There were 240 pence to the old (pre-decimalisation) pound, comprised of 20 shillings each worth 12 (old) pence. Do you remember guineas, crowns, half-crowns, shillings, tanners (6-penny piece), threepenny bit, pennies, half-pennies, farthings (a quarter penny)? I do. I suspect that I am quite a bit older than you and I cannot ever remember there being 120 pence to the pound. So either please provide a citation or confess that you are mistaken/talking bollocks. :-)

But the main thrust of your post was correct with regards to dividing sums of money easily. Or at least it was until the education system decided that mathematics and mental arithmetic were not the most important subjects in life. I'm not sure how some of today's young people could cope with such problems.

Re:Don't have to.

[SnowZero]

You're off by a factor of 3600. It's "leap hours" that are being proposed; We already have leap seconds. Of course, I'm not sure the math from TFA makes too much sense anyway, as I don't recall having an average of 3 or 6 leap seconds every year.

Re:What would be wrong with

[Tony Hoyle]

This is the same problem as the witching hour every year when switching to and from daylight savings time. The remedy for that is to ensure you don't schedule jobs for those hours, or get vendor assurance of what, exactly, will happen for jobs scheduled at the start, middle or end of the witching hours.


Nope. cron, like all Unix services, runs to UTC and doesn't give a crap about daylight savings time.

Re:Metric time?

[PhunkySchtuff]

Hey, wait - seconds are base 60? What kind of bizarrity is this?

No, minutes are base 60 - you can count seconds in any base you want as they're a unit.

Re:South.

[FireFury03]

I live at 5 degrees east. Thus, I know that because I'm at GMT+1, the sun will be exactly in the south at 12:40 PM. ...Except the exact time the meridian passes under the sun varies throughout the year since the Earth's orbit isn't circular.

Don't get me wrong - I think removing the leap second is just silly but your point is rather bogus.

See http://www.timeanddate.com/worldclock/ [timeanddate.com]

Re:Metric time?

[porkchop_d_clown]

You need to look into your history of science more closely. Joules, Volts, Watts, were all adopted by the metric system, not created by it.

No edit needed

[Anonymous Coward]

There are two seperate subjects debated in TFS. Read: Subject 1: the removal of leap seconds debate. "..a proposal to remove leap seconds from UTC...There is some debate as to whether this change is a good or bad idea" Subject 2: the debacle of a solution. "a 'leap-hour' in about 600 years, which nobody seems to believe is a good idea" It's fine

30 Febuary

[daveewart]

Historically, there have been some 30 Februarys: http://en.wikipedia.org/wiki/30_February [wikipedia.org]

Re:Simple and accurate solution

[odyaws]

Run computers on TAI (International Atomic Time). Keep it constantly flowing, and never add or remove seconds, as per the definition. Then simply calculate UTC in software from a published leap offset between the two, which compensates for the leap seconds:

UTC = TAI - leapseconds

Then define all the timezones off of UTC as normal.

This is basically what they do in one area I have experience in where keeping precise track of time is important: spacecraft navigation. Ephemeris Time [wikipedia.org] (not actually obsolete as the article claims) is generally referenced as the number of seconds since January 1st, 2000, 12:00:00 TT, is the "official" time that you work with when computing the positions of heavenly bodies (and spacecraft). The transformation from ET to UTC (the human-readable time) changes when leap seconds are added. When using UTC to compute the position of things, you use the history of leap seconds to convert correctly from UTC to ET, then use ET to figure out where things are.

Obligatory Quote

[scruffy]

"It 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." - IEEE Standard 1003.1b-1993 (POSIX) Section B.2.2.2

Re:Simple and accurate solution

[evanbd]

Interestingly enough, that is exactly the relationship between GPS time and TAI. It's defined the other way, obviously, but GPS time does not have leap seconds, and the GPS signal includes the size of the correction needed so that receivers can display UTC time.

Re:Other way

[Manhigh]

Space probes/satellites also are sensitive enough to rely on leap-seconds. If you dilute these by breaking them up throughout the day, figuring out ephemerides would be complicated.

Re:What would be wrong with

[arth1]

Cron may think in UTC, but the crontab is in the system's local timezone.

Worse, different systems have different implementations. There's bsd, sysv and vixie's implementations, plus numerous variations, and all seem to do their own stuff.

An example: You have four boxes located in the :Europe/Paris time zone, one Solaris box, one AIX box, one HPUX box and one RHEL box, with daily jobs scheduled at 01:00, 01:30 and 02:00. Let's call them job1, job2 and job3.
Which of the three jobs will run on each box on March 30, 2008?
Which of the three jobs will run on each box on October 26, 2008?
Which of the three jobs will run twice on October 26, 2008?

If anyone (except perhaps Arthur D. Olson) can answer that without investigating, I'd be very surprised.

Sometimes the vendors themselves can't say for sure, due to the time adjustment occurring in a different process, and depending on availability of interrupts and CPU time on the system, the cron interrupt may see either the old time or the new time when it wakes. One of the above vendors thus recommends that jobs scheduled for the start/end of the witching hour are moved one minute outside it.

Anyhow, the parent to your post deserves to have the "+1 Informative" stripped, because it's plain misinformation.

Regards,
--
*Art

One thing's for sure

[DaveM753]

No matter how this is resolved, in the end Microsoft will screw-up the time zone patch.