Earlier quoted context omitted.
There is a solution for this, Unix timestamps.
That fails for the case that you have an appointment at 3pm in 30 days, and 15 days later the timezone's offset changed.
UTC Is Enough for Everyone, Right?
171–180 of 321 posts
Re: UTC Is Enough for Everyone, Right?
#172Earlier quoted context omitted.
IMO the biggest problem isn't the how you store information or even do the date-math. The most frustrating thing is drawing out user-intent, distinguishing between two use-cases which are so similar that most users won't even know what they want. Specifically, future events which aren't tied to a geographical location, and ones which are. And in the latter case, determining which single location it should be pegged t…
Another example of confusing user-intent is "last X days". I.e Does "Last 2 days" indicate: A. Last 48 hours? B. Yesterday + Today up to now C. Yesterday + the day before.
Re: UTC Is Enough for Everyone, Right?
#173Earlier quoted context omitted.
That fails for the case that you have an appointment at 3pm in 30 days, and 15 days later the timezone's offset changed.
How does that fail? I have an integer for an appointment. I am at that appointment at that given integer. This applies for all timezones. If the timezone changes, the integer does not. What you are saying is that the timezone changes and the integer changes aswell, but then it's not the same appointment anymore.
Of course, if you have a meeting that spans timezones, this is unavoidable. I think the real solution actually lies in how the meeting time is expressed to the user so they don't have misconceptions about it.
Re: UTC Is Enough for Everyone, Right?
#174Re: UTC Is Enough for Everyone, Right?
#175> It's most likely because you have twelve joints in your hands: three in each of the four fingers, excluding the thumb. I thought that was pretty nifty to discover. Like, I had never looked at my hands before, really. Hands are really wild, when you think about it.
Probably not. This explanation of duodecimal is really farfetched and I’m pretty sure it arose from someone staring at their hands desperately trying to come up with a way to count 12 on their fingers to explain this. (Ten fingers and two feet seems as likely.)
Clocks are (probably) divided into (two sets of) 12 hours for the same reason feet are divided into 12 inches. Because it’s convenient for everyday use. Subdivisions of 1/12th suck for complex math (if your number system is decimal anyway), but are great for lay use. 12 subunits captures halves, thirds, and quarters, all of which are very intuitive and very common in everyday use.
12ths are handy enough that we have a special word for “12 of something” (dozen) even though our numbering system is decimal.
Re: UTC Is Enough for Everyone, Right?
#176That was an efficient way to heat a battery.
Re: UTC Is Enough for Everyone, Right?
#177> If you're like me and immediately said ohhhhhhhhhhhh, so THAT'S why there's twelve hours in a day! and immediately followed it up with: wait, why the fuck are they using twelve instead of ten? ... > It's most likely because you have twelve joints in your hands: three in each of the four fingers, excluding the thumb. I thought that was pretty nifty to discover. Like, I had never looked at my hands before, really. Ha…
My understanding is that the etymology of dozen is originally traced back to duodecim (Latin for twelve) via French dozeine. Which is interesting, but doesn't really explain why it's special beyond your observation that it's a highly composite, but comfortably small, number.
Re: UTC Is Enough for Everyone, Right?
#178Earlier quoted context omitted.
I don't think I ever heard of anyone (besides scientists) to store timestamps in TAI. Though Ada supports leap second calculations in the standard library: http://www.adaic.org/resources/add_content/standards/05rat/h...
Dealing with time well into the future is rough because of the unknown timezone changes and unknown leap seconds. There's not much you can do. Computing future times in TAI from user inputs in wall clock time is fraught, so I guess you can't store TAI in those cases. For a calendar app, since users want to deal in wall clock time, you have to store time with timezone and with leap seconds (so UTC + time zone). And yo…
Why would getting rid of leap seconds from UTC be a problem for that?
The reason there are leap seconds is nothing to do with wall clock time, it's because some people feel the time ought to be intimately connected to the Earth's rotation, but the Earth doesn't oblige by rotating steadily.
In my view the people demanding this relationship be maintained ought to take responsibility for fixing it from their side. Speed up or slow down the Earth. Can't? Too bad then, but don't expect us to keep fiddling with the clocks.
Re: UTC Is Enough for Everyone, Right?
#179So the article seems to imply you should store all timestamps as UTC (with an additional timezone string ID). But for events in the future that needs to happen on a specific "wall clock point in time", it might be better to actually store the yyyy-mm-dd hh:mm:ss as a string with a timezone next to it, because timezones can and do change often unpredictably. If you pre-calculate what "4.00pm next August 1st" is as a U…
There is still a caveat, though. Locations can change timezone. Sometimes they do it fairly often (like every few years). You need access to a good timezone/location database that is updated regularly :-(
When we were doing this project, I was really surprised at how often we got problems. If you sell things all over the world (there are golf courses in ridiculous places), the probability that you will stumble into an anomaly is surprisingly high. Alas, this project was not a commercial success as the margins on tee times are quite small (and the tee time services you have to work with are often quite badly written). But it was quite fun to work on.
Re: UTC Is Enough for Everyone, Right?
#180The Brits did this for their railroad in 1847. Time balls were used to synchronise clocks before telegraph and radio.
https://en.wikipedia.org/wiki/Time_ball
On clock accuracy, I was reading last night about time dilation due to gravity, and the difference in time rates from points less than one meter apart in height on earth have been experimentally verified.