121–130 of 133 posts
Earlier quoted context omitted.
No they won't. The idea that 12am is night and 12pm is day is pretty well entrenched in society.
While I understand your point, I find that a surprising number of people have issues with 12am vs. 12pm, often confusing the two. These same people tend to think midnight occurs at the end of the day.
In the future, the world will use UTC and sunrise and sunset will happen at different times, relative to where you are.
No they won't. The idea that 12am is night and 12pm is day is pretty well entrenched in society.
Earlier quoted context omitted.
This seems like it would cause more problems than it solves. "It's 10:00 here in London. I need to call someone in New York, what time is it there?" "10:00, same as it is everywhere in the world." "So... is now a good time to call them?" "I have no idea."
I'd imagine it would be much easier to remember "business hours in NYC are between 1200 and 2030 UTC," than remembering the time difference and applying a translation every time.
Earlier quoted context omitted.
No they won't. The idea that 12am is night and 12pm is day is pretty well entrenched in society.
jorangreef is probably right, at least assuming that we get to colonise other worlds. I mean, what does it mean to talk about 'day' when you're on the ISS? How are Martians going to deal with the fact that they have a Sidereal Rotation Period of 24h37mins? Or the Moon, with it's roughly 700hr SRP.
Edit: We basically just need a logical clock though we may face problems reconciling this logical clock in a distributed space/time system.
Earlier quoted context omitted.
The article should add a caveat: use UNIX time when you are recording the current time to store for later use. That can always be formatted in the user's current timezone to display back. When you're inventing a rule system based on local times, as you are above, of course you need to track the rules in the local time zone. That's because the rule is: "do this thing at 9am in my particular local time zone", not "do t…
And that doesn't even get into the problem of the DST dates changing at the whim of legislation like it did recently in the US about 5 years ago. If you are attempting to track timezone instead of UTC you've now have to check date ranges when different DST was in effect. Very messy stuff. Better to just keep it in UTC or Unix if you need the offset it was recorded in as you mentioned.
> Timezones are a presentation-layer problem! I want to correct this common misconception that UTC is enough. Calendar time with all human traditions involved is more complex than a simple timestamp. The advice above is incorrect for calendar and scheduling apps, or anything that has a concept of a repeating event. An example: we have a weekly meeting occurring 9AM Monday in San Francisco. You are in London and want…
UTC is enough for - as the article suggests - storing a date. Storing a recurring class of dates is - of course - more complicated; but then has anyone ever suggested otherwise?
Note also that not all governments are in the habit of giving sufficiently advance notice of daylight saving changes.
Earlier quoted context omitted.
You're right. It should say: Unix time is the number of seconds since epoch, not counting leap seconds.
Any idea why it was done this way? It seems like counting leap seconds belongs in the same layer as sorting out timezones, i.e. not here.
Not to mention that you can't know the UTC-TAI offset more than a few months into the future. We can not predict which years will have leap seconds inserted.
Unix timestamps do not handle leap seconds well at all. Obvious things like t₂-t₁ fail to provide the number of seconds between t₂ and t₁.
Does NIST (and other sync tools) keep in mind the round-trip of a request (RTD / RTT)?
(It assumes symmetry because there isn't any way to measure the asymmetry without first having time sync, and obvious catch-22. If you need better than 10ms accuracy, you'll need a GPS, etc.)