251–260 of 275 posts
Earlier quoted context omitted.
The international date line isn't straight in order to avoid land. Moving it would be problematic.
think of it as ordinal: you're shifting left 1 unit, not moving the line, per se.
> So far, there’s never been a leap second removed in practice (and the Earth’s slowing rotation means it’s unlikely) Oh, okay. Thanks!
Perhaps a stupid question: Why isn't there a time standard that is monotonic and defined simply in terms of seconds, without attempting to match the movement of the earth (no leap seconds, no negative seconds, no daylight savings, no complicated calendar politics)? If such standard existed, wouldn't it be the best to use for programming, with "simple" conversions to/from the all the other standards? Basically, I want…
Unix time is set up to allow programmers to assume every day has the same number of seconds. Is this the best approach, or would it have been better to try to educate everyone not to make that assumption and to use a standard library for all UTC calendaring?
Earlier quoted context omitted.
think of it as ordinal: you're shifting left 1 unit, not moving the line, per se.
Still matters because some places want to make sure it's the same day (according to their local reckoning) as it is somewhere else in particular (usually a major trading partner).
I've been thinking about datetime APIs and how most of them become extremely tedious when you have to account for daylight saving, countries changing time zones et cetera. I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing. But then I considered leap seconds. I don't know if there are libraries tha…
> I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing That does not and can not work when trying to represent future local events, which is the vast majority of them as an event normally happens relative to a specific geodesic location. Astronomical events are more or less the only ones which actual…
Posix defers to ISO C where they differ: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
See page 391. The encoding of Unix time is explicitly unspecified there.
Posix goes on to say: http://pubs.opengroup.org/onlinepubs/9699919799/
“ The time() function shall return the value of time [CX] [Option Start] in seconds since the Epoch. [Option End]”
So, Unix time is optionally seconds since the epoch, with no further guidance about leap seconds.
Also, the spec makes it clear that time_t needs to be converted into the appropriate time zone, which suggests it does not reflect leap seconds.
I’d be convinced by source code or documentation for both BSD and Linux showing they’re intentionally not posix compliant on this front, and apply leap seconds to Unix ticks and not their time zone conversions.
Earlier quoted context omitted.
> Move any jumps in time to once a century (or millennium). You hear a lot of people remarking that Let's Encrypt has made things better by requiring certs to be reconfigured more often rather than less. I know they're not exactly the same as time in general, but as a general idea, knowing that you need to do some fiddling often and automating it, might be better than growing complacent because nothing needs to be do…
It's almost as if we've tried something like that in the past, and the effort to avoid the worst issues was a monumental effort.
I read articles like this and come to the conclusion that UTC is flawed, not Unix time. Leap seconds seem mostly useless. People seem to think they are important for astronomy, but for every astronomical calculation I have ever done, your first step is converting from UTC to TAI. Move any jumps in time to once a century (or millennium). Such jumps have occurred in the past (Julian to Gregorian) and are easy to handle…
Some people think one year is one orbit around the sun, and not exactly 365 days. Leap years help to keep that reality. Some people think that a day is one revolution of Earth's axis, and not exactly 86400 seconds. Leap seconds help to keep that reality. The fact that axial rotation is less predictable than orbital paths is a quirk of nature.
Here's my version of it:
Some people think one year is one orbit around the sun, and not exactly 365 days. Leap years help to keep that reality.
Some people think that a day is one revolution of Earth's axis, and not exactly 1440 minutes. Leap minutes help to keep that reality.
And now we are at less than one change every century!
Earlier quoted context omitted.
The earth doesn't travel the same course each year. It's chaotic. Best to define a second as a certain distance light travels in a vacuum and use that to build minutes, hours, etc. Then, have a fixed geo reference point (like, say, geo 0:0) that holds an atomic clock as a main reference. We are only really talking about local coordinate changes in the time dimension, really, so might as well simplify.
> The earth doesn't travel the same course each year. It's chaotic. I would prefer to call it quasiperiodic.
Emprically it seems to be after but that seems wrong; shouldn’t the result of the command be the same regardless of how long it takes to type the sudoer’s pw?