Vote Ron Paul for President and he'll take us off this fiat time that the government has us on. Sun Dial Standard!

WTF Indeed: Vote Ron Paul for President and he'll take us off this fiat time that the government has us on. Sun Dial Standard!

There is just one moon and one golden sun. Coincidence?

/It's a small world after all.

But what about muh tomato plants?!??!

Huh?

Clock of the Beast?

cretinbob: Humans are only using 1 of the 4 existing days available to them.

Interesting. Speak to me of corners and being educated stupid.

Yeah yeah, I've heard this all before



You know who makes a big to do about time? Somebody who gets paid to be a "time director". Coincidence?

"I got no time for time" -Chong

The problem is that most systems written since 1972 have implemented the leap second. Far more than those that haven't, in fact. We can either leave the system as it is now, only be required to fix those systems that were incorrectly programmed, and allow international time to continue matching astronomical time. Or we can change all of the systems that were written correctly in an attempt to make the incorrectly written systems not matter. This is a stupid debate, IMHO, and it's likely that the main supporters (politicians?) are ones that would like to see a bump in programming jobs available (similar to Y2K).

I just want it to be March again...I'm sick and tired of the sun going behind the western hills at 3:30 pm.

What a Time Director might look like.

Time is an illusion, lunchtime, doubly so.

Somebody had to make the reference...

screw it, let's just move on to metric time.

UTC is your friend.

lohphat: Stop using the iPad optimized content as it blocks pinch-zooming. I can't read the small print and need to enlarge the text.

If pinch-zooming is blocked, I would think that's the exact opposite of iPad-optimized.

TheFlyingGoat: The problem is that most systems written since 1972 have implemented the leap second. Far more than those that haven't, in fact. We can either leave the system as it is now, only be required to fix those systems that were incorrectly programmed, and allow international time to continue matching astronomical time. Or we can change all of the systems that were written correctly in an attempt to make the incorrectly written systems not matter. This is a stupid debate, IMHO, and it's likely that the main supporters (politicians?) are ones that would like to see a bump in programming jobs available (similar to Y2K).

The biggest problem with leap seconds is that they cannot be accurately predicted; they are the product of observation, and they are distributed only a few months before the necessary adjustment.

This means that disconnected systems cannot keep UTC accurately, even if they have high-precision clocks onboard.

(Why yes, I am working on an embedded, disconnected system...)

The nice thing about removing the leap second is that we don't need to reprogram anything: we simply stop the notifications that would otherwise generate the leap second adjustment. So this isn't any conspiracy to create jobs; it's actually streamlining in a couple of different ways.

Now that I've actually read TFA, I'm struck by this: "We are using a system that breaks time (the clock says 58, 59, 59 and then it passes to the first second of the next minute). The quality of time is continuity. This is why a majority in the international community want to change the definition of UTC and drop the leap second."

If that's the problem, why not just count to 61 in that leap minute, instead of repeating 59? That way the clocks stay accurate AND the quality of time is continuous. Elementary, my dear Watson!

Baloo Uriza: UTC is your friend.

That made my brain hurt!

As well as reaffirming my dalliance into trying to grasp these concepts is weak at best.

NOAA Chart 1 is difficult enough with the definitions of sunrise, sunset, twi-light, and the use of navigational aids.


Plus the other comments in this thread are going to make me read and think on this dismal day.

Thanks?

lohphat: Dear Slate,

Stop using the iPad optimized content as it blocks pinch-zooming. I can't read the small print and need to enlarge the text.

Stop republishing articles from other sites without a URL to the original. Mentioning the source at the end of yur re-published piece which just take te reader to the top of the site is lazy.

You should probably ask for a full refund

How about simply counting cumulative seconds for GPS and the like? Not like that's a novel idea. Does clock time really matter there?

What a Time director might look like:

Amusingly, we can't simply adjust the lenght of a second as the astronomical corrections are not clock-regular.

Easiest thing to do is eliminate the leap seconds, let the astronomers deal with it for their needs [since a computer can solve the correction automatically for 'em], then punt the future down the road - a minute in 100 years should not be too hard to correct then if it's critical.

Stellar navigation tables will have to be adjusted to compensate, but these are printed annually, should not present an issue.

Other than the editors and writers who won't have the filler article to publish whenever we add a leap second, I can't see any serious downside to making the change.

The only people who notice the leap seconds are the people who need them to go away. The people who will biatch about changing it the most are the average folks whose clock are almost certainly off by several seconds, maybe even minutes, anyway. So if they make the change, you're GPS, cell phone, and probably your computer will always be accurate, but your other clocks (the ones you change twice a year) will be whatever you make them depending on what you use for a standard. Much the way it is today. This is no big deal.

Change it, just don't make a big deal out of it so the rabble won't freak out.

StoneColdAtheist: Now that I've actually read TFA, I'm struck by this: "We are using a system that breaks time (the clock says 58, 59, 59 and then it passes to the first second of the next minute). The quality of time is continuity. This is why a majority in the international community want to change the definition of UTC and drop the leap second."

If that's the problem, why not just count to 61 in that leap minute, instead of repeating 59? That way the clocks stay accurate AND the quality of time is continuous. Elementary, my dear Watson!

Because most programs that deal with time aren't going to accept a seconds value over 59.

StoneColdAtheist: Now that I've actually read TFA, I'm struck by this: "We are using a system that breaks time (the clock says 58, 59, 59 and then it passes to the first second of the next minute). The quality of time is continuity. This is why a majority in the international community want to change the definition of UTC and drop the leap second."

If that's the problem, why not just count to 61 in that leap minute, instead of repeating 59? That way the clocks stay accurate AND the quality of time is continuous. Elementary, my dear Watson!

This is how it is implemented, at least on some computer systems (e.g. Unix/Linux). The seconds field is defined as going from 0 to 60, inclusive.

Meh. Their Time Director has nothing on this guy:



/obscure?

The Loaf:

When they decided to implement IPv6, it was decided that human-readable addresses, while nice, weren't all that necessary. Why don't they just do the same for machine-based time keeping? One standard, in a machine readable format, that's then translated to human readable format when (and only when) a human needs to read it? (Like UNIX has been doing since midnight on Thursday, January 1, 1970.)

But how many seconds has it been since midnight of Thursday, January 1, 1970? There are applications that need to know that, and right now, the people that write those applications have to use some lookup table or other ad hoc means to figure this out. That's what they're complaining about, and why they want to change it, so that they never have to use these means again, and it's easier to write their software.

The tradeoff of switching to a flat time is that in a few centuries, noon (that time when the sun is roughly at its highest point) will no longer occur at 12PM for your timezone, but at some other time in the day. Sure, it takes a long time, and I won't be alive then, but somebody sooner or later has to deal with it, and then it's not a second or two here and there, but several hours that have to be added or subtracted. The root cause is not the length of the second, it's the non-constant rotation rate of the earth, with its semi-random variations. Nothing we do while maintaining a constant second is going to fix that problem (and trust me, we really want to keep the second at a constant duration).

So the current system is a compromise. The few people in society that have to worry about high-precision timing have to take pains to be accurate, while the overwhelming part of society that only cares that noon is when the sun is at the highest point goes on about their lives (seriously, have leap seconds ever impacted the average person?). The proposed change will make it easier on those relatively few guys that write high-precision timekeeping apps, while putting off the major adjustment to everybody at some unspecified time in the future.

Personally, I'd like to keep it like it is. Sure, it's a pain once every few years, but we know how to handle it already. I don't see what the big deal is, and we're never going to get around the true problem anyway (the inconstant earth rotation rate). And if you need a continuous system, there's atomic time, which UTC is already calibrated to anyway.

WTF Indeed: Vote Ron Paul for President and he'll take us off this fiat time that the government has us on. Sun Dial Standard!

Works for me. I hate having the Sun at different points in the sky whenever I wake up. Plays hell with my biological clock, which is the one that matters to me.

StoneColdAtheist: If that's the problem, why not just count to 61 in that leap minute, instead of repeating 59? That way the clocks stay accurate AND the quality of time is continuous. Elementary, my dear Watson!

Actually, that's how UNIX (and Linux and anything conforming to POSIX) supposedly do it. Their struct tm allows the "tm_sec" field to go to 60. The actual UNIX time is just a time_t that counts seconds since January 1, 1970, regardless of leap years, leap seconds or any other shenanigans. (The time_t was originally a 32-bit number, leading to the upcoming Y2038 problem. 64-bit systems tend to not have that issue.) The conversion to our Babylonian-inspired sexagesimal-derived rendition happens for display purposes only.

Updating the leap second behavior is just a matter of getting updated timezone files, just like we do whenever Congress dinks around with when DST starts/ends here in the US. Eliminating the leap second doesn't really simplify things on systems with date stamps in the past, since to correctly render the time, you need to know the DST rules that were in place at that time, not whatever today's rule is.

im14u2c: Actually, that's how UNIX (and Linux and anything conforming to POSIX) supposedly do it. Their struct tm allows the "tm_sec" field to go to 60.

I should say, "go 0 to 60, allowing for 61 seconds."

Gone_Feral: But how many seconds has it been since midnight of Thursday, January 1, 1970? There are applications that need to know that, and right now, the people that write those applications have to use some lookup table or other ad hoc means to figure this out. That's what they're complaining about, and why they want to change it, so that they never have to use these means again, and it's easier to write their software.

That's what the timezone database is for. It can handle Indiana. It doesn't even bat an eyelash at leap seconds.

Do all your "monotonic time" stuff in "epoch seconds", and only convert to human-readable time when needed. There's no great reason for the computer to do math directly on human-readable time, any more than it makes sense for computers to do math directly on a length expressed as a combination of miles, yards, feet, inches and mils. Just put everything in one common unit (mils, feet, or whatever makes sense for the problem), and split it back into pieces at the end if you need to.

Unavailable for comment.

/"Is this how it all happens for you? Slowly, and in the correct order?"

You know who else liked to meddle with time?

This is retarded. In fact using hours/minutes/seconds/days, etc. is retarded except at the very ends of the processing chain, where you're inputing or outputing data for a human user. Internal time on all such time-critical applications should be a single 128-bit integer representing picoseconds since a time epoch, no exceptions. Or, hell, why not yoctoseconds? That'll cover most advanced physics uses that need more precision than picoseconds, and it won't be exhausted for ten million years.

lohphat: I didn't know that GPS time is off from UTC by 15 seconds.

Precise time is critical for GPS calculations especially in differential/WAAS mode

precise timing is fundamental to how GPS works; so precision is always critical for GPS calculations

/just sayin'

valkore:

All this article did for me was make me realize that I have very little understanding of how time is calculated, and that I will be dead in the year 2600. Fark you subby.

You haven't seen the half of it. Wait until you see when we start factoring general relativity into it. ;)

aerojockey:

This is retarded. In fact using hours/minutes/seconds/days, etc. is retarded except at the very ends of the processing chain, where you're inputing or outputing data for a human user. Internal time on all such time-critical applications should be a single 128-bit integer representing picoseconds since a time epoch, no exceptions. Or, hell, why not yoctoseconds? That'll cover most advanced physics uses that need more precision than picoseconds, and it won't be exhausted for ten million years.

Of course that's retarded. That's why nobody in any level of professional computational sciences does that. We've gotten past that centuries ago. But the discussion isn't about internal representations, it's specifically about those "very ends of the processing chain." Monotonic timekeeping still has to relate back to human observables at some point. Epoch time 31,546,234.2354555654452 seconds doesn't mean anything to a human, even the one doing the computation. If a human is involved, it's always going to come back to YYYY/MM/DD hh:mm:ss.ssssss, or some variant thereof. Most humans are going to also want that representation to be meaningful relative to the events in their lives, like day and night cycles, and Friday night at the pub. And there's the rub, because those things aren't as regular as one might think. Well, maybe Friday night at the pub is.

And don't be defining what precision you think I'm going to need to do my computations. Stick with the standards for human representation, and let each of us worry about what we need to do our work, and how we'll relate it back to the standard. Seriously. Mitts off my computational techniques, or I'll bite one of your fingers off.