101–110 of 275 posts
This guy is confusing Unix time with local time. This statement: > Unix time is the number of seconds since 1 January 1970 00:00:00 UTC Is true regardless of the calender or leap seconds. Think of seconds in terms of some physical phenomena, like how many times a certain atom trapped in a crystal lattice vibrates and you see that doesn't depend on the calendar. Converting Unix time to local time obviously has to take…
> But it’s unsatisfying to say “this is false” without explaining why Got my upvote. I can't stand the "falsehoods programmers believe" articles that make a point out of not backing up any of their claims.
This is all over dramatized myth busting -- one could simply say they are all true except for the occasional leap second adjustment. No need for the dramatic "they are all false."
;)
Earlier quoted context omitted.
> The different time definitions exist to support different use cases. UTC isn't flawed, in fact the adjustments that keep it aligned to solar time are very helpful for its defined use cases. The user above listed several explicit cases that seem needlessly complicated. Can you give examples where the adjustments to UTC are so helpful for its defined use case? Or elaborate what that case is? I'm not trying to be obst…
We humans almost always want our concept of "what time is it" to correspond to the relative motion of the sun in the sky. We ask "what time is sunrise?", and "when will the days start getting longer?". We like "noon" to be when the sun is highest in the sky. All those things are what UTC is designed for.
[1] I'll save the rant on DST.
https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...
Here are 20 more links: https://github.com/kdeldycke/awesome-falsehood#dates-and-tim...
So, if I adopt smearing for my NTP, everything works fine.
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…
Astronomy has the need for both. A notion of an instant in time that advances linearly without any ambiguities, which would be TAI, and a notion of the precise orientation of Earth, which would be UTC. To record events, you will use TAI, to point your telescope to a celestial object, you will use UTC.
You still need something that keeps track of the Earth's rotation, but presumably the ITU will still keep track of the difference between UT1 and UTC. I'm an (ex-) astrophysicist, but I'm not convinced that astronomy would actually be particularly impacted if leap seconds would stop being applied to UTC. You already need to keep a leap second table, it would just shift where you apply it.
Earlier quoted context omitted.
Well, the problem with this is that every simplistic view at time is... well... too simple. It's not that many people haven't tried, I especially like this article: https://qntm.org/abolish That being said, why your approach doesn't work is that there are several hard astronomical or cultural definitions that you'd throw off by playing with time. A day is defined as the rotation of the earth around its axis. A week i…
The third principle of Continuous Delivery is "If something is difficult or painful, do it more often". So, if leapseconds are actually painful for you, then maybe we need to contemplate making this kind of adjustment on a finer timescale, like milliseconds. OTOH, if you think leapseconds are painful now, just you wait until you postpone this pain and do it even less frequently.
That only works assuming you need to do it at all.
If leap seconds are useless (to the majority of users) or insufficient, not doing them is preferable to doing them constantly.
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…
I deeply disagree with point 3. Unix Time actually never goes backward: it just stagnates during a leap second. The article uses fictional fractional second to argue the contrary but I don't think it makes much sense. Unix Time is represented an integer and has no concept of such a fractional unit. That's an important distinction because it means that if you use Unix Time as a timestamp you can actually be sure than…
POSIX defines gettimeofday [1], which fills a timeval with integer (time_t) seconds and integer (suseconds_t) microseconds. Is your concern over weather Unix Time is a time_t or a timeval? A time_t shouldn't go backwards (in normal operation), but a timeval does. [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/ge...
gettimeofday gives you a struct timeval with microsecond resolution.
clock_gettime (which takes an extra argument specifying which of several clocks to use) gives you a struct timespec, with nanosecond resolution.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/c...
chrony[1] neatly solves these and a host of related issues by guaranteeing time increases monotonically on a given host, speeding up or slowing down the clock appropriately. It's a nicer alternative to ntpd. Also, AWS recommends it if you are using their Time Sync service (which is GPS-locked atomic clocks in every region with leap second smearing). [1]
And it has done so for probably at least ten or fifteen years.