351–360 of 456 posts
Earlier quoted context omitted.
Perhaps another moral to add: ISO8601 solves a lot of problems.
This is a misconception. ISO8601 has six versions, is 14 pages long, and defines way to many ways to represent dates and times. Everyone should follow RFC 3339. https://www.rfc-editor.org/rfc/rfc3339#section-5.6
Earlier quoted context omitted.
> Sometimes the best solution is not a technical solution I once came across an early 1950s Scientific American article by Bertrand Russel, IIRC. It included a cartoon. Frame one: Computer beats man at chess. Frame two: Man unplugs computer.
How about this? Frame one: man beats woman at chess. Frame two: woman shoots man with automatic pistol. Not sure how deep the original really is if you think about it...
Earlier quoted context omitted.
Yeah, they could have been working on something truly valuable like violating people’s privacy with ad-tech. Or maybe sucking millions of hours of people’s lives away with TikTok algo improvements. Maybe they could be working on the next MoviePass! > zero sum game of stock arbitrage. By your definition insurance is zero sum as well. But people find that generally useful. Taking risk off of peoples hands has value eve…
> Yeah, they could have been working on something truly valuable like.... But why not just a reasonable product? Yes, what could that be, there cannot be something that is fairly priced and people really want, need, what just helps. Not today anymore! > By your definition insurance I know what you try there and on a very abstract level you are maybe slightly right, but PLEASE no, high level gambling (==milliseconds&m…
Earlier quoted context omitted.
clocks get used for two distinct purposes, often at odds: - the measurement of durations. - the presentation of some timestamp in a way that the reader has some intuition for. that first purpose won’t be hurt by not tracking leap seconds. actually, a lot of applications will probably more accurately measure durations by eliminating leap seconds. if leap seconds (or minutes) really are of critical importance, we’ll re…
I agree with your separation between "duration" and "absolute point in time". But it doesn't solve the issue, because durations are often computed as the difference between two absolute points in time. You could get over this on your local machine with a local counter, but across network boundaries you need to rely on absolute differences.
other way around. e.g. unix time is determined by the number of seconds (as experienced by some point fixed to Earth, roughly) relative to some reference point. duration is the native format for most time systems, like UTC, because “absolute time” isn’t a thing that can be measured. faking the duration (e.g. adding leap seconds) within a time system is sort of nonsensical: we only do it to make translation across time systems (UTC, UT1, local/human timezones) simple. if that’s the justification for things like leap seconds, then better to keep the time system itself in its most native format (assuming that format is useful locally) and explicitly do those conversions only when translating, i.e. at the network boundary: when communicating with a system that doesn’t share/understand our time system(s).
Earlier quoted context omitted.
My favorite is comparing aggregated data across several time zones when DST changes happen.
Shouldn't you just aggregate based on UTC? Leap seconds still cause a problem here but daylight savings shouldn't matter.
Earlier quoted context omitted.
My favorite is comparing aggregated data across several time zones when DST changes happen.
Shouldn't you just aggregate based on UTC? Leap seconds still cause a problem here but daylight savings shouldn't matter.
I've heard of the endless disruption that leap seconds cause for years and only now have I thought to ask the question: what was so important that the entire world needed to add or subtract individual seconds from the calendar? Seems like you'd need a pretty big justification for something like that, but I only here the horror stories, not what the leap second was supposed to actually solve.
Mostly due to tidal friction from the moon, Earth’s rotation is slowing down in the long term. If we don’t adjust our clocks, the difference between the solar day and our clocks will slowly grow, quadratically. See this site for more details and nice graphs: https://www.ucolick.org/~sla/leapsecs/ In 1972 it was decided that the best way to compensate for this is to insert (and sometime remove) leap seconds, so that t…
Earlier quoted context omitted.
> Sometimes the best solution is not a technical solution I once came across an early 1950s Scientific American article by Bertrand Russel, IIRC. It included a cartoon. Frame one: Computer beats man at chess. Frame two: Man unplugs computer.
How about this? Frame one: man beats woman at chess. Frame two: woman shoots man with automatic pistol. Not sure how deep the original really is if you think about it...
Earlier quoted context omitted.
Fintech covers the entire payments space too
Guess I'm thinking more of HFT. Normal payment processing isn't this affected by a leap second though as far as I know.