241–250 of 275 posts
The author uses graphs with quarter-second increments because they make it look weirder. It's not that weird for time to standstill for 1 second.
Earlier quoted context omitted.
> you should only store timestamps of past events and events that happen at a fixed instant regardless of calendars and wall clocks as Unix timestamps I think this works more often than not, but it's hardly foolproof or without repercussions. Say, you can imagine Google Calendar having a list of holidays for the US. Say it's New Year's day. You're saying you'd replicate that into 6 epoch timestamps (one per time zone…
Yes. This sounds a bit silly for New Year in particular because its timing is slightly less arbitrary than other holidays', but holidays move around: https://en.wikipedia.org/wiki/Uniform_Monday_Holiday_Act
Earlier quoted context omitted.
> you should only store timestamps of past events and events that happen at a fixed instant regardless of calendars and wall clocks as Unix timestamps I think this works more often than not, but it's hardly foolproof or without repercussions. Say, you can imagine Google Calendar having a list of holidays for the US. Say it's New Year's day. You're saying you'd replicate that into 6 epoch timestamps (one per time zone…
This is a trick question - for whole-day events, the best way to handle them is to record the calendar day you want them to happen on, not the timestamps of the start and end of the day in some particular timezone. See what iCal does with DATE versus DATE-TIME (which must be UTC or include TZ): https://tools.ietf.org/html/rfc5545#section-3.3.4
Earlier quoted context omitted.
This discussion isn't going to be very meaningful unless you wanna tell us what 'best' means to you.
That's fair. I simply can't see the best solution relying on getting rid of deeply ingrained culutural norms that span thousands of years.
Not to mention with climate change, we're probably going to have to deal with many other changes in season etc. anyway.
All of us deal with the fact that the day gets shorter and longer every year anyway (and daylight savings didn't seem to be a terribly good solution).
I think having the seasons slowly drift is a non-issue, provided it's just slow enough to not be noticeable from year to year.
* Every standard library needs properly implemented and properly documented functions for converting between UTC and TAI.
* NTP should (at least optionally) tell the user TAI and UTC (like GPS already does).
* When mounting a legacy file system there should be an option to specify whether timestamps should be interpreted as TAI or UTC.
* New filesystems should have a field that specifies TAI or UTC. It would probably be a single bit for the whole filesystem rather than per timestamp.
* The CLOCK_UTC proposal should be implemented, with tv_nsec in the range 1000000000 to 1999999999 during a leap second.
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…
Not at all.
To quote Feynman: "Nature cannot be fooled".
The earth will rotatate in a (slightly) chaotic fashion. Midnight has a definition which is based on astronomy.
Thus, you need to adjust the length of a second (which is not desirable) or the number of seconds in a day.
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 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.
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 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.
I would prefer to call it quasiperiodic.