> I'm not sure what a correct system should be, but I know that it can't be based on the Earth, the sun, or any one galaxy. In order to have accurate time, it must be external to all of these things, like a meter stick is to an object.

But Einstein's theory of relativity makes that impossible -- there is no absolute time. The larger reason for debates like this is because any timekeeping convention is relative.

As to a "meter stick", that's also relative, and therefore arbitrary, for the same reason -- relativity theory.

"3:00 pm" is in the middle of the night, the time to wake up for work will always "change"..

well, one time .. but do you !really! care about how the folks in +600 yrs measure time? I'd guess they invent some kind of "glacial-period-light-saving-time" by then...

Well, we're still using the Gregorian Calendar, and according to Wikipedia, that was released in 1582 [1]. When designing a system as eternal as time, I believe that it should still be easily usable in 100, 600, or 10,000 years; on any planet, and in any galaxy.

[1] http://en.wikipedia.org/wiki/Gregorian_calendar

I know it's a joke, but it's lazy programming/lazy thoughts like this that caused the issues with the systems in the first place :)

Although I still don't fully understand why leap seconds caused such a problem - we can handle leap years and we can handle daylight savings, surely this is just another clock correction action such as these?

The problem with programming for a leap second is you don't know when a leap second will occur. Compare this to a leap year, which happen every 4 years, always. Leap seconds are sporadic [1]. Programming a clock to accept the time of 11:59:60 only on occasion is trivial in a web app, but slightly more complex in a firmware or high-reliability system like flight controls.

[1] https://en.wikipedia.org/wiki/Leap_second#Insertion_of_leap_... (see the chart at the side)

Thanks for the explanation, makes sense. I see what you mean about the sporadic nature of the insertions!