Earlier quoted context omitted.
They teach us Scientific Realism in school, but reality is that we are really using Instrumentalism. That said, no one wants to admit it, so contemporary science follows Falsification, where we find ways to not actually make claims about reality. (Which as an Instrumentalist/pragmatist, I love Karl Popper, its just not metaphysical truth. And that would break Popper's heart)
No they do not teach Scientific Realism in schools. We're taught the scientific method and then build upon that. I can see how someone could misunderstand or forget what they're taught though.
No leap second will be introduced at the end of June 2026
91–100 of 159 posts
Re: No leap second will be introduced at the end of June 2026
#92Re: No leap second will be introduced at the end of June 2026
#93Back in the early 2010s my company was maintaining a Spring application processing ActiveMQ messages. We'd received word that the application wasn't processing work. One of us goes and looks at logs and sees just endless volumes of stack traces. Eventually the suggestion is made and accepted to just reboot the application. That fixed it. Turns out the JVM simply lost its mind when leap seconds were introduced. So, fo…
Re: No leap second will be introduced at the end of June 2026
#94Google and lots of other firms use a "leap smear" to hide the leap second from end users, essentially "smearing" the second across the hours before and after each leap. https://developers.google.com/time/smear
Re: No leap second will be introduced at the end of June 2026
#95[0]: https://en.wikipedia.org/wiki/International_Atomic_Time
Re: No leap second will be introduced at the end of June 2026
#96Computer systems (most importantly, UNIX) should've been using TAI [0] from the beginning. Human-readable time in turn should be computed from it using periodically updated time zones database which would include offset between TAI and UTC. By eliminating leap seconds we effectively re-invented TAI with a weird offset. While I am in favor of eliminating leap seconds as a hacky way to fix the current mess, it's sad to…
We convert timestamps to and from date+times all the time. Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that. Leap second smearing will ensure smooth and continious time.
Taking leap seconds into account is only needed in a very, very few contexts - maybe astronomy, or certain kinds of high-speed physics? Those rare users should be able to figure stuff out.
Go with UTC, don't optimize for rare usecases at the expense of everyone else.
Re: No leap second will be introduced at the end of June 2026
#97Re: No leap second will be introduced at the end of June 2026
#98Re: No leap second will be introduced at the end of June 2026
#99Really the idea that there will enough civilizational continuity that our current timekeeping infrastructure and systems will continue unbroken for that long is insane.
Re: No leap second will be introduced at the end of June 2026
#100Computer systems (most importantly, UNIX) should've been using TAI [0] from the beginning. Human-readable time in turn should be computed from it using periodically updated time zones database which would include offset between TAI and UTC. By eliminating leap seconds we effectively re-invented TAI with a weird offset. While I am in favor of eliminating leap seconds as a hacky way to fix the current mess, it's sad to…
No, they should not. We convert timestamps to and from date+times all the time. Having each day be exactly 86400 seconds simplifies this a lot, and practically every app benefits from that. Leap second smearing will ensure smooth and continious time. Taking leap seconds into account is only needed in a very, very few contexts - maybe astronomy, or certain kinds of high-speed physics? Those rare users should be able t…
>We convert timestamps to and from date+times all the time.
If you do not account for time zones during this conversion, then you are not qualified to implement such conversions.
It's fine to use 86400 seconds for durations (e.g. "this computation will finish in 1d 8h 20m 34s"), but it's absolutely not fine to use it while dealing with datetimes.
[0]: https://en.wikipedia.org/wiki/Leap_second#Phase-out_and_futu...