Slashdot Mirror
Leap Second May Be On the Chopping Block (ieee.org)
szotz writes: The days of 61-second minutes may be coming to an end. The World Radiocommunication Conference is meeting for nearly the entire month of November, and one of the hot-button issues is what to do about the leap second. The addition to UTC is supposed to keep atomic time aligned with Earth's rotation, but past leap seconds have caused server crashes, and some are worried that future problems could be even worse. Going into the conference, it doesn't look like there's much of a consensus on what to do. One official is expecting weeks of debate.
So people write crappy code and rely on it without adequate fault tolerance strategies and that's somehow the problem of people who measure time? I think not.
John
Leap hour, wait until 3600 leap seconds build up, then add the spare hour that night pushing midnight to 25:00 (or 13:00AM) in all complying time zones.
Daylight saving, leap seconds, flouridation. They're all part of Agenda 51.
P.S. And systemd.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
So the means to synch the servers exist, right? Or is this very out of date view of computer and the clocks?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
While I'm sympathetic for all the folks who want to drop the leap second, given an appropriate amount of time the difference will add up. It seems to me the problem is quite simple which is to publicize the leap second a bit more than it is now. It is an education issue -- at least no more or less than leap days and that seems to work just fine all in all.
Perhaps Facebook can create a viral leap second post. Much better than viral kitty posts.
There has to be some humor in "weeks of debate" over a second.
I mean: leap seconds might make sense or they might not. But... crashing servers? Seriously? Has anyone of you observed that?
(OK, you will possibly have to adapt time "softly" over some period to keep the clock monotonic, but if you are doing real time stuff sensitive to = 1sec you'll have another time reference anyway).
In my 35 years, I've always seen time as a counted measure of how much time has passed since I started counting. I seem to be forever learning that's my novel idea.
Why should I care where the sun is, where the moon is, where the earth is, with respect to time? If it's winter, I can start work at 9, I can start at 10, I can start an hour after sunrise. I don't need to adjust my clock to start work at the same clock-display every day. I see nothing wrong with a company that has different business-hours by the season.
Similarly, since I'm not in the old west, I don't care if "high noon" is an noon, or 1, or 1 second after noon. I've never determined the time based on the sun.
Last I checked, we have perfectly wonderful time-keeping and gps devices these days. So ocean ships and submarines no longer need a sextant and a chronometer to figure out when and where they are.
So here's my petition. I'd like time to always move forward, and the same rate of 1 second per second. I'd like it to not jump, leap, crawl, rewind, fast forward, restart, end , or eject.
Shit, I just realized that I'm not 35 years old. Or I am 35 years old, but not when measured in seconds. Wait for it...ok, now I'm 35 years old. Phew.
Hold up, slow down.... Wait just a second...
We are going to debate this for weeks? The solution is clear and the question is easy... How close do we need to be to the astronomical time? Once you answer that, we all know what to do.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
It must either deal with it or be designed to fail gracefully. It's not like we have a choice.
Naturally: the earth's rotation must be sped back up to match the clocks.
This avoids any trouble with legacy systems crashing and so forth, and is likely easier to implement.
... are doomed to reinvent it, poorly.
Seriously, programmers need to get over it. There is not a damn bit of possibility that a fixed-size physical unit of "the second" will be adequate for timekeeping without inserting some form of leaps. The leap is not a programming issue. It is a fundamental feature of our Earth and its rotation. If you don't want to write software for Earthlings, go somewhere else.
There are plenty of systems for time that *don't* involve leap seconds.
If your system's too crappy to be able to deal with leap seconds or you don't have a way to update them, use TAI or GPS time.
Don't screw with the definition of UTC just because you can't handle the complexities of it. It's not like someone's forcing you to use UTC, UT1R, or one of the other UT systems that are specifically intended to deal with issues of local noon.
(disclaimer: I work for a group that deals with solar observations*)
* and even one of them almost screwed the pooch and didn't distribute the update for the June/July 2015 leap second until 3 days before it happened ... and of course it was compiled in (for speed, they claimed**) rather than be an external file.
** if it really was for speed, then they need to flip their giant if/then structure so it starts in the present and walks backwards in time, rather than how they're doing it now where it runs dozens of tests that will always fail for a spacecraft that wasn't launched 'til 2010.
Build it, and they will come^Hplain.
How close do we need to be to the astronomical time?
My argument would be that we don't. Who cares if the seasons shift to different months over a few hundred years? It's not going to be important within the lifetime of anyone reading this. If it snows in June instead of December I just don't see that as an actual problem. Pick an epoch and count from there. No need to keep the seasons matched to the calendar for eternity. In fact if we leave Earth, doing that will quickly become highly impractical.
...and it was still too short.
What in the wide world of sports is this?
I don't know what it is that drives a certain set of computer nerds to demand the rest of the world change their practices and deal with the cascading list of effects, just because said nerds find something inconvenient or annoying.
This is so much like the "everyone needs to switch their lives to UTC" droning... it's just not funny anymore.
#DeleteChrome
The problem is that the leap second shows how your systems fail if there is a synch problem or delay in time propagation. So removing the leap second merely means you won't find the bug and fix it when you know what the most probable cause is.
Dealing with 61 or even 62 seconds in a minute would be required even if it were due to a lag of time updates causing 59 becoming 59 a second later, then maybe 59 another second after that, which could happen if the time servers propogate incorrectly.
But try debugging that situation. Even the proximal cause is hidden because all you see are timestamps of :58 going to :59 and then going to :00.
So, yeah, totally remove leap seconds.
Because it's inconvenient dealing with time that isn't 100% monotonically increasing, like computers will do.
Shouldn't we be timing the world against a pulsar star instead of the earths rotation?
An old-timer?
Il n'y a pas de Planet B.
The addition to UTC is supposed to keep atomic time aligned with Earth's rotation, but past leap seconds have caused server crashes
So some day it'll be dark at noon, but our buggy software will still function.
that'll hold the little bastards
if this is supposed to be a new economy, how come they still want my old fashioned money?
I appreciate that its necessary to adjust the clocks to celestial bodies as appropriate. But why do it all at once, and suffer from the aftereffects.
When a leap second WOULD have been declared, have the NTP stratum-1 servers bias things a bit until the -1 and astro-time match, and let the world catch up over the next few hours/days (one tiny increment at a time).
No software glitches. Tiny differences between systems, but we always have those anyway.
Astronomer's and other's that really care, use -0 time adjusted directly ... or adjust their local clocks for a bit.
The days of 61-second minutes may be coming to an end
Wait... are they getting rid of days, seconds, or minutes?
systemd is Roko's Basilisk.
Leap-seconds were properly handled in computer software before most of today's software engineers and programmers were born.
Back in 1969, I started working on a software system that already handled leap-seconds quite smoothly. At that time, keeping UTC aligned with the rotation of the earth involved introducing fractional seconds and also having UTC seconds NOT the same duration as atomic seconds (TAI). In 1972, this was simplified by having UTC seconds exactly the same duration as TAI seconds and (after an initial fractional leap) introducing only leaps that were full seconds. The software in the system on which I was working DID NOT HAVE TO CHANGE!!.
Internally, the system on which I was working -- which evolved and continued in use to operate military space satellites for over 20 years -- kept all time in TAI, which never has leap-seconds. A relatively small routine converted in either direction between UTC for displays and TAI for internal time. Another small routine converted from UTC to UT! to sidereal time, the latter more closely reflecting the rotation of the earth, which is gradually slowing and also has predictable periodic fluctuations. The purpose of all this was that we needed to know very accurately the spot on the rotating earth directly under the orbiting space satellite. The position of the satellite was known in TAI while the surface of the earth was rotating very closely to sidereal time.
Also note that the network time protocol (NTP) also accounts for leap-seconds and has done so for decades.
I can only conclude that the current attempt to do away with leap-seconds is a result of lazy software "professionals" trying to shift blame for their ignorance about leap-seconds.
But do you care if high noon is at midnight?
NO! I really don't. The number is just arbitrary. I don't care if noon occurs at night or during the day. I don't care if winter occurs in June or December. I think all of that is pointless complication to keep the calendar matched to rotations of the Earth and orbits of the Sun. Keep the time keeping simple
I actually like the idea of time being counted as orders of magnitude of seconds. A kilo-second is roughly 1/4 hour. 100kilo-seconds is just over a day. A mega-second is about 11 days. Basically a metric sort of approach. The only unit that should really matter is the second and there is no reason to adjust our timepieces or calendars to match arbitrary astronomical events.
Frankly if we really wanted to keep synchronized to orbits we should have defined the second to be (close as possible) some divisible fraction of the time of revolution of the earth. (pick the kind that you like - sidereal, stellar, whatever...) But since we didn't, we either need to use a second order number (some multiple of a second) to define time or just not worry about it.
Make water boil at 200F and make pi be 3 again!
That was the turning point of my life--I went from negative zero to positive zero.
Find the maximum acceptable delta between noon being when the sun is actually in the sky and UTC and only issue leap minutes when that delta has been exceeded. Leap minutes would make this a far less frequent event. It will take years before 12:00 is 12:01 and we have to issue a correction.
Astronomers are smart enough to be able to compensate for a known few seconds of arc offset between the astronomical time and clock time. For the rest of us, having the timezone drift to the side is not going to cause any noticeable difference in the position of the sun for several centuries.
Exactly, and it REALLY doesn't matter if summer comes in June or December. We're just used to it a certain way but that doesn't mean it has to stay that way. Folks living 1000 years from now wouldn't know the difference anyway.
Did find this on wikipedia though Under the proposal, leap seconds would be technically replaced by leap hours as an attempt to satisfy the legal requirements of several ITU-R member nations that civil time be astronomically tied to the Sun. So I guess these nations might still be causing problems, disliking this clunky workaround.
Then those folks can handle the workaround themselves or get on board with the program. If they want to be a special snowflake then they can deal with the problems that causes. The rest of the world uses the metric system even though the US insists on sticking with US Customary Units and that works out ok (mostly).
Every time something craps out due to a leap second, they fix it, which means the # of things which can fail next time is less.
Lather, rinse, repeat, and problem solved.
Incompetent people like to shift problems to someone else. They're already trying to shift problems like "national debt", pollution,and "climate change" to the future generations and now they want to shift another problem to a future generation.
I would prefer better coding and testing standards to be the norm. At the moment, every time a problem occurs because of a "leap second" it's noticed and fixed with a reminder that this is something to be watched and tested for. I would like to think that handling it would become part of the standard QA procedures, actually it should have already been part of QA, it's not new, this has been happening for over 40 years!
If they think a "leap second" is a big deal then a "leap minute" or "leap hour" is going to really cause problems. They'll have longer periods of time for more bugs to accumulate and when they happen everything will have problems because either they'll fail or something they depend on will fail.
More often than not these issues stem from people trying to roll their own time handling code / int'l address code / i18n / etc rather than using one of the standard (and well-tested) libraries available in their language.
In some cases, the well-tested library is a third-party library that ships with neither the language nor the default install of the operating system. This leads to "I couldn't get the application to start because I couldn't figure out how to follow the instructions to install the required third-party library" or "I couldn't get the application to start because I lack privileges to install the required third-party library." A company may think rolling one's own good enough library is cheaper than fielding these support calls.
Or the well-tested library is either proprietary or copylefted and cannot be lawfully combined with a copylefted or proprietary application respectively. This affected me at work when I was looking for transliteration libraries to make addresses in foreign scripts recognizable to the U.S. Postal Service, but the good one that everyone recommended was GPL (not LGPL), and the boss chose that we roll our own rather than make our own application free software.
in the same time, we could get rid of summer/winter time change
aaaaaaa
Okay boys and girls, I've people talk repeatedly in these comments about leap seconds in the context of the earth's rotation around the sun. That's not what leap seconds are for. Leap seconds are for keeping the clock in sync with daylight hours. If you let it drift, sunrise and sunset drift, not the seasons.
Because the primary function of time since the dawn of civilization has been to allow human activity to synchronize with the position of the sun, from planting seasons to night watches.
Most human beings have lives that are affected by sunlight.
The sunlight will happen at its own schedule whether or not we set our watches and calendars by it. We use Daylight Saving Time in large part precisely because the standard definition (noon = sun at highest point) doesn't actually work well for many of us. I don't really care if daylight starts at 7am or 7pm and it won't change fast enough within my lifetime for it to affect me much.
Same reason we should get rid of that DST crap. Simple = far fewer accidents.
Yep, go to DST year around. I have no use for daylight during working hours or during my morning commute. I do have a use for it after I get home. DST all year!
Scheduling life and work based on a pulsar would need to somehow override the biological tendency of the human body to synchronize its activity cycle to sunlight levels, which are correlated to the earth's rotation relative to Sol more than to a pulsar.
We let "one year" drift enough that it only needs to be corrected once it's off by a whole day. Why not let [86,400] seconds accumulate and have a second leap day every hundred thousand years or so?
Because sunlight levels over a day control more recurring human biological processes, such as alertness, than any natural phenomenon with a year's period.
Time isn't hard to get right. We have just done done a wonderful job of making it complicated. A second is defined as a fixed period of time based on what was thought to be 1/60th of 1/60th of 1/24th of a day. As we get better ways of accurately measuring a day, we just haven't redefined it.
1) Redefine a second to account for leap seconds, leap centuries, and any other extra corrective increments we might need to apply. We now know really well how to measure the Earth's rotation accurately, and we could even account for relativity by taking in altitude if you want to be really accurate. A lot of hardware will need to be updated, so this seems impractical.
2) Ignore leap seconds altogether. Why do we need the time to match when the sun is overhead during a solstice anyway? Why do you need time zones at all? Is it really important to have everybody in the word getting up at 8 am and going to bed at 10 pm? It is important to know that California is 8 hours ahead of GMT, but the actual local time is just a number. Ignoring leap seconds will cause gradual time drift, but if we stop trying to force a discrete calendar onto non-integer time cycles, the problem just goes away.500 years from now, the winter solstice might be in June in the Northern Hemisphere, but honestly, who cares?
HA! I just wasted some of your bandwidth with a frivolous sig!
But the primary function of time today, is not to synchronize activity with the sun. Today, it's to synchronize human activity with other human activity, often across great distances.
It's both. It's to synchronize human activity with other human activity, some of which also happens to be synchronized with the sun over the course of about a week.
The number of broadcast networks who said "the game starts at 7" for a game being played by two teams local to different time-zones!
It refers to the time zone of each terrestrial broadcast station's market, either the city of license or of the nearby major city that it serves. A signal at the permitted transmission power of a radio or TV station license usually doesn't reach far outside the intended time zone. A station licensed in a city in a different time zone would describe the start of the match relative to that city's time zone: "the game starts at 8".
Hey, one network even said "...at 7 ET". There is no such thing as ET. There's EDT, and there's EST. You figure out which one they meant.
Unless the event is near 2 AM Sunday morning on the transition day, it can be easily calculated from whether or not applicable law in the station's market applies DST on the date of the event.
The main reason for aligning clocks with the sun is for navigational methods that aren't really used anymore.
You mean like the human biological tendency to be active at certain hours before and after peak outdoor light?
At this point, it makes much more sense to have a fundamental time reference that provides 60 seconds to a minute, period, and if you really want to translate to your local sun-referenced time, make use of translation tables.
Theoretically this "fundamental time reference" is TAI (International Atomic Time, and the leap second history acts as the "translation tables" you describe between TAI and UTC. The problem is that UNIX adopted UTC as the basis for its timestamps.
remember how Y2K was supposed to crash all civilization because bad code in the bowels of all infrastructure and control systems could not deal with the rollover from 1999 to 2000? That didn't happen much. I am still here. How is it that a 1 second error brings down a server?
SLASHDOT: news for people who can't concentrate on work or have no life at all and got tired of yelling back at the TV.
The ITU-R first received this issue as Question 236/7 in year 2001. They have spent nearly 15 years coming up with this list of 6 methods for dealing with leap seconds. In that note the most recent "Method D" from a group of countries who prefer no change because they are not satisfied with the documents that have been submitted to the ITU-R during the past decade.
The debate continues because it is not a technical issue. We know how to count SI seconds by physicists watching cesium atoms, and we know how to count calendar days by astronomers watching the earth rotate. The question is about time producers and time consumers -- which of the time producers will have the hegemony, and whether the time consumers have enough agency to choose what time scale to use for their applications. The question is whether the days of the civil calendar will remain related to the rotating earth, or change to be 794 243 384 928 000 hyperfine oscillations of cesium-133.
Let's adjust the movement of the Earth instead. We just need to get the AIDA experiment right and scale it up a bit.
The ITU-R first received this issue as Question 236/7 in year 2001. They have spent nearly 15 years coming up with this list of 6 methods for dealing with leap seconds. In that note the most recent "Method D" from a group of countries who prefer no change because they are not satisfied with the documents that have been submitted to the ITU-R during the past decade.
The debate continues because it is not a technical issue. We know how to count SI seconds by physicists watching cesium atoms, and we know how to count calendar days by astronomers watching the earth rotate. The question is about time producers and time consumers -- which of the time producers will have the hegemony, and whether the time consumers have enough agency to choose what time scale to use for their applications. The question is whether the days of the civil calendar will remain related to the rotating earth, or change to be 794 243 384 928 000 hyperfine oscillations of cesium-133.
Because the Y2K bugs got fixed.
The one second leap second bugs: not.
if (xx15
Playing with various values of 19 and 20 for xx and yy and figure what would go on is left as an excersise for you!
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
How do you write down business hours on a door with that system?
Similar to how we do it now. Our current date and time system works from an epoch so it's really not much different. You'd need some sort of offset for a day for purely practical reasons. There are about 86164 seconds in a sidereal day but adjust the number to something close the actual rotation. Then it's just a multiple of that number from the epoch. Then you post the business hours as 32 kiloseconds to 64 kiloseconds. (that would be about 8 hours) Label the work week however you like. Could even remain the same as it is now if we like a 7 day week, though it might make sense to make a "week" 10 days or 5 days.
If software developers would unit test their shit, this wouldn't happen.
“Common sense is not so common.” — Voltaire
APK on a good day...
Atomic and earth time will always differ
Folks run in earth time.
Lawyer says auction at courthouse steps at noon, requires a legal definition of earth time.
Airline says plane board at X time is in earth time.
Machines run in atomic time.
It provides a nice, smooth, continuous time stream.
In order for folks to use machines, the 2 systems have to work together.
This currently means that the 2 system's seconds tick together, but the labels for the seconds change from time to time.
Assuming the 2 systems continue to tick together,
the leap second discussion is about when the label relationship will change.
Instead of having an occasional leap second, we might force our grandchildren to have a leap minute party at the turn of the next century.
Unless you happen live in Greenwich and are married to the idea of the sun being directly overhead at noon,
this seems a reasonable and fun compromise.
Wait until it adds up to an hour, then do an extra DST. Why do today what you can put off for a few decades?
-==- Buy a Mac and leave me alone!
I'd define a second to be exactly 1/86,400th of a day (where a day is the time for the earth to rotate about it's axis in reference to the sun)
Thereby making each second a unique length of time. Each second going forward is slightly longer than the previous one. For consistency of measurement you must specify which second you are referring to. For example give me a second*, will ya? *The second that will occur on April 30, 2017, 16:07:54 UTC.
That was the turning point of my life--I went from negative zero to positive zero.
To me, this is like trying to legislate that pi equals 3. Like it or not, the Earth's rotation doesn't "behave" to our convenience. Getting rid of leap seconds is a massive step backwards, so after awhile the Earth's day doesn't align with the time we keep. Eventually, a fixed adjustment would need to be made, as has been done in the past when the problem wasn't handled as elegantly as leap seconds now do - and that's even more of a hack. The fact that servers crash just means that their software is poorly written in the first place and should be fixed. Many more servers than those isolated examples of problems, have handled the event just fine in the past, so it's not that hard to do. The simple solution - computer clocks kept synchronized internally to atomic time (TAI) which progresses simply and uniformly without caring about leap seconds and the Earth's rotation. Then, when humans need to view the time in a manner convenient to them, it's converted to local time which does account for leap seconds. No computer crashes, as it's just then a time display issue. Too bad Unix time doesn't already do this. If legislators wanted to get rid of needless and pointless complication, I'd much rather see them banning Daylight Savings Time... but that's another discussion.
If you don't want the solar time and UTC to drift many seconds out of synch, but are willing to let the alignment between the two to drift by more than a second at any given time, then using the long-term average rate of rotation slowing to calculate regularly scheduled leap seconds seems the way to go.
We add whole leap days at regular intervals, but it does not seem to cause any problems because everyone knows when they occur, even millenia in advance. It is not possible to schedule leap seconds that far in advance, but using an average trend over the last 20 years (perhaps), and the cumulative planning miss over the last decade, to plan for the next decade (say) would not allow deviations of more than a couple of seconds from solar time to ever accumulate.
Look at a chart of the deceleration of rotation over decades.
Second class citizen of the New Gilded Age
Shift workers have to do it. And it's what you do anyway. How about stop making the clock lie and change when you get out of bed if you don't like when you get up?
Why should machines use UTC at all?
We have a time standard that doesn't use leap seconds - Atomic Time (TAI). We can convert between the two fairly easily.
So why not instead push for software to use TAI in place of UTC, and then convert for output or whatever? We could just have leap seconds in our time zone files and forget about the machine actually experiencing 23:59:60 at all.
Those who can't do, teach. Those who can't teach either, do tech support.
That a server crashes when the NTP software updates is bad. And its not the atomic clock peoples' fault. And its not NTP's (the Network Time Protocol software that syncs a computers internal time clock with a remote accurate time server) fault. Its the software on the server that crashes the box. Its bad that it crashes the server. So fix the crap software. FIX IT! Don't say "oh its my blah blah blah system and I can't shut it off or fix it." No. Fix it or don't use NTP. There are systems that can slough systems in (slowly changing the time a few hundredths of a second per day till they are in sync). The worst are those who tell other people that they need to stop keeping accurate time. The time is the dog, and they are the tail. Tails can be cut off. Keep time accurate.
No, on his really good days, he does helpful things like getting access to /. from Tor blocked.
Il n'y a pas de Planet B.
Following from Google's strategy, but spreading it out quite a bit so it would be more convenient and less devastating to tracking applications, YET would completely remove the leap hiccup from the IT world which seems to be the main concern...
Why not agree to install a few 'shims' at all the world's stratum-zero sources that start a linear drift of 1 second over the course of six months to a year before the 'scheduled' leap second deadline? Then once the drift crosses the 1 second mark the shim is automatically disengaged? The drift would be precisely accounted for and measurable in GPS sources but would be hidden well below the noise level of NTP sync.
If the drift would create a problem, it may only require specialized software to 'un-drift' the signal for those few high precision applications that already contain nanosecond-capable hardware and (presumably) a firmware update cycle.
Just a few shims and some international coordination in place of umpteen million software changes or a clock drifting further out of sync... and the world's consumer GPS and Inter-networks would be infinitesimally off the mark for awhile?
If you'd like to read what might be the world's only science fiction short story about loss of NTP sync, see my tiny yarn here on Slashdot, The Time Rift of 2100: How We lost the Future --- and Gained the Past.
<blink>down the rabbit hole</blink>
Use the agile principle "If something is painful, do more of it". So we should introduce UJT, Universal Jitter time, where a control signal makes every third minute 60, 59 and 61 seconds long respectively. That makes sure that software can deal with all these cases on a routine basis. The control signal can then be adjusted to skip one of these in the cycle when a leap second is needed.
I read SuricouRaven's post as referring to a DNS blacklist, which is the proper way to implement DNS-level blocks. Why are you promoting the worst way to interact with DNS?
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Speed up the earth, using solar-powered electric rail-guns at the equator to shoot depleted uranium at near-relativistic speeds, increasing the angular momentum to overcome losses.
Thank you. Next, can we get rid of Daylight Savings Time?
Don't mess with the clocks - you can keep them accurate and adjust the display format for leap seconds, just like you do for leap year days, time zones, Daylight Savings, US-vs-EU Daylight Savings, etc. Yes, this means that some people won't fix their code, so they'll be off by a few seconds from consensus, but time will continue to be monotonically increasing so stuff won't explode. There are also people who write code that doesn't handle leap years properly (I'm less bothered by the people who only do Year%4 than the ones who check for Year%100 but don't check Year%400 .)
And I haven't seen a Y2K bug in the field in, oh, at least a month or two (I forget if it was the "year=19100" bug or a different one.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
remember how Y2K was supposed to crash all civilization because bad code in the bowels of all infrastructure and control systems could not deal with the rollover from 1999 to 2000? That didn't happen much. I am still here. How is it that a 1 second error brings down a server?
Yes, I remember spending a lot of time fixing those bugs. Thanks for giving those of us who worked hard to prevent a problem zero credit, asshole. Just because your job doesn't involve time accuracy doesn't mean mine doesn't. Me personally, I need to keep scientific instruments at different locations synchronized. Leap seconds are a total pain in the ass for us.
There never was any Y2K bug. There was a bug in 1986 where the 32 bit word in memory rolled over (I think it was 16:46 on a Thursday).
Anyway, all the unfixed OS and applications at financial houses (TRW, etc) went down and they lost millions in the week or so it took to fix.
The same folks the neglected to take take action in 1986 were "experts" warning of the "same" issue in 1999.