I do prefer to drive over a bridge that is well designed, but if that bridge is found to have design flaws, I prefer to have them fixed right away. I do not want to wait for the crew to build a second identical bridge next door in order to test their patches.
How about if, having built the bridge, they could build a second one in a few minutes for a dollar or so, store it out of the way in hyperspace, and swap the two at will? Would you still not want them to work on the offline one? Read I35 Bridge before you answer.
Files and messages get time-stamped with system time. These files and messages get used by other systems. Thus it is important that different machines agree on what system time is. We have such an agreement: the standard called UTC. We are proposing to change that standard, but we need to get everybody to agree to the change. This makes it more than an OS implementation detail.
This is exactly what should be done. Since Unix time does not include leap seconds, it is discontinuous--either skipping a second, or repeating the same one twice
Only on remarkably poorly configured systems. Others skew the clock by slowing it down until it is correct (usually using Chrony or Ntpd). The clock is never stepped. It is still wrong during the slewing period, however.
Like leap years, leap seconds should only concerned when the time is needed in date form--after all, both of their goals are to keep our calendar and time of day in sync with solar time.
Yes. Like local time, UTC should be something that is generated on request from system time and a lookup table. System time should be TAI or an offset thereof.
I assure you that the excellent sound system gives you all the auditory warning you need.
Yes, a few assholes with such sound systems go past my house from time to time. They give me "auditory warning" when I'm inside a hundred yards from the road.
The idea is to define UTC as TAI plus a table of corrections instead as series of random length segments of TAI seperated by discontinuities. You would generate UTC times by applying corrections to TAI as needed instead of attempting to operate your clock on UTC and having to jump it around every few years.
If we went clear back to 1965 you could attend college classes in astronomy that included the teaching that the sun could not produce as much energy as it does with nuclear reactions without having too short a life span. The calculations of that era suggested that gravity was the most likely source of solar heat generation.
University of Lower Slobbovia, 1966? Solar fusion was first hypothesized by Eddington in 1920 and fairly well-understood by 1939.
systems where humans expect the time to be correct (which is probably many of the Oracle DBs) should use something we have already had for a long time: adjtimex and its equivalents, which implement systematic drift.
No. They should never store local time. They should store time in a universal form (presently UTC, we are suggesting TAI) and convert to local time for display.
Instead of suddenly adding or removing one second, just make the second longer or shorter for a few minutes/hours/days (depending on how quickly you need it to be synchronized with UTC vs. how much shift your systems can tolerate w/o getting confused). The solution is simple, and already exists.
And is how it is actually done. Unfortunately, it means the the system time is wrong while the clock is slewing.
The display routine looks at 23:59:60 and goes *BOOM* just the same as it did with the UTC codes.
TAI (number of seconds since the TAI epoch) would be converted to UTC by simply adding the appropriate number of seconds. UTC is a discontinuous scale consisting of segments of atomic time seperated by leap seconds. "23:59:60" is the conventional way of displaying those discontinuities. You can't get away from them as long as you insist on displaying UTC-based local time, but you can at least move them to the display routines that already have to deal with DST and time zones and get them to hell out of the fundamental timekeeping software.
I do think the -programs- need to be fixed, rather than the leap seconds dropped (although I don't see any serious problem with that either.. leap second-aware apps would simply see no further leap second insertions
I don't see that applications should ever need to be aware of leap-seconds.
...and it wouldn't be an actual issue until many centuries later.
There is no need for it ever to be an issue.
...but saying that the programmer should switch to TAI is oversimplifying things.
The whole issue should be transparent to the application programmer.
No, there is a good reason to not use TAI. That reason is that humans are not computers and our brains do not tell time like an atomic clock. TAI will eventually tell us that 12:00 is at sunset and that's not something humans will (or should) accept.
That is not a reason not to use TAI. It's just a reason not to display TAI when a human asks for the time. The machine can keep time in TAI and use a lookup table to convert to UTC for display as is already done to convert UTC to local time for display. It merely requires the addition of a field to the timezone tables and it is what we are proposing here.
Slashdot Mirror
If you run down a pedestrian you could have avoided "He was jaywalking!" is not going to be an effective defense.
> I expect better from Slashdot editors...
New here, aren't you?
> Or was that the 70's?
1980: it came with early versions of MSDOS. I avoided ever learning it by using CPM/86 and Unix.
> These systems have high-level I/O options (keyboard, monitor) that embedded systems don't...
Some embedded systems have serial I/O and support terminals.
Uhm, we were saying that in the 1980s. At Bletchley Park they should be teaching with machines that actually are old.
How about if, having built the bridge, they could build a second one in a few minutes for a dollar or so, store it out of the way in hyperspace, and swap the two at will? Would you still not want them to work on the offline one? Read I35 Bridge before you answer.
> There's a difference?
Sure. The monkey is trained.
> This is why there is a change control process...
There is? Where? Many sites exhibit evidence of change and others of control but I don't recall seeing evidence of both on the same site.
> How about not disgruntling the employee in the first place?
Some employees disgruntle themselves.
It's a planet if it is on the list of the nine planets. Pluto is. Eris isn't. Either that or we go back to the original five.
Files and messages get time-stamped with system time. These files and messages get used by other systems. Thus it is important that different machines agree on what system time is. We have such an agreement: the standard called UTC. We are proposing to change that standard, but we need to get everybody to agree to the change. This makes it more than an OS implementation detail.
Only on remarkably poorly configured systems. Others skew the clock by slowing it down until it is correct (usually using Chrony or Ntpd). The clock is never stepped. It is still wrong during the slewing period, however.
Yes. Like local time, UTC should be something that is generated on request from system time and a lookup table. System time should be TAI or an offset thereof.
Yes, a few assholes with such sound systems go past my house from time to time. They give me "auditory warning" when I'm inside a hundred yards from the road.
Right, but US-bashing is obligatory for some.
In many jurisdictions they are likely to be ticketed for that.
Honda makes Civics. Honda used to make little high RPM motorcycles which were, in ancient days, known as "ringy-dingies". For the sound they made.
Whoosh. Twice. Read my sig.
Nine.
> And what do these people do to avoid people on bicycles...
Nothing. Bicycles are absolutely, totally harmless.
The idea is to define UTC as TAI plus a table of corrections instead as series of random length segments of TAI seperated by discontinuities. You would generate UTC times by applying corrections to TAI as needed instead of attempting to operate your clock on UTC and having to jump it around every few years.
The speakers go "Ring-dingy-dingy", right?. But, no, I guess that woulf be for Civics.
University of Lower Slobbovia, 1966? Solar fusion was first hypothesized by Eddington in 1920 and fairly well-understood by 1939.
No. They should never store local time. They should store time in a universal form (presently UTC, we are suggesting TAI) and convert to local time for display.
And is how it is actually done. Unfortunately, it means the the system time is wrong while the clock is slewing.
TAI (number of seconds since the TAI epoch) would be converted to UTC by simply adding the appropriate number of seconds. UTC is a discontinuous scale consisting of segments of atomic time seperated by leap seconds. "23:59:60" is the conventional way of displaying those discontinuities. You can't get away from them as long as you insist on displaying UTC-based local time, but you can at least move them to the display routines that already have to deal with DST and time zones and get them to hell out of the fundamental timekeeping software.
I don't see that applications should ever need to be aware of leap-seconds.
There is no need for it ever to be an issue.
The whole issue should be transparent to the application programmer.
That is not a reason not to use TAI. It's just a reason not to display TAI when a human asks for the time. The machine can keep time in TAI and use a lookup table to convert to UTC for display as is already done to convert UTC to local time for display. It merely requires the addition of a field to the timezone tables and it is what we are proposing here.