Why is subtracting these two times in 1927 giving a strange result? (2011)
stackoverflow.com
stackoverflow.com
e.g. UTC still has leap seconds kludged in from time to time "because the Earth's rotation speed varies in response to climatic and geological events" [1]. There's been talk of redefining it at some point to remove them.
GPS Time or Precision Time Protocol may be suitable when you need to measure events on a continuous scale.
Leap smeared time used by Google and AWS is also an interesting topic [2].
Time smear is an interesting concept. Once enough of the world’s clocks are synced to online sources, I wonder if we should consider using that kind of idea to smear away daylight savings time over the whole year. Not sure it’s a great idea, but maybe it would be possible to set the sunrise to be 7am every day.
Some years ago I sketched a way to do smoothed DST based on when the sun rises. The trick is to avoid time zone differences due to differences in latitude (as well as longitude). I chose to use sunrise at the nearest tropic as the benchmark, which gives you a gradual DST adjustment of about an hour and a half between winter and summer, changing by up to a minute or two each day. http://catless.ncl.ac.uk/Risks/search?query=Sunrise+time+Fin...
RISKS is one of the oldest mailing lists, since 1985, worth subscribing if you have an interest in computer systems security.
Also, why stop at sunrise, and discriminate against sunset? Do what the Romans did: always have 12 hours between sunrise and sunset and 12 between sunset and sunrise (https://en.wikipedia.org/wiki/Roman_timekeeping#Variation) :-)
12 hours of sun is a crazy idea, now that's some time smear. It'd be funny to try that in Iceland or Svalbard, where you'd end up with days where 12 hours are divided into 10 minutes... or worse, some days with no hours at all!
You can try different times on this page, for one:
If you really want to complicate things, a real “7 ‘o clock at local sunrise” clock should also be affected by local mountains.
If you really, really want to complicate things, include cloud cover, too, an require that sunrise must be observed (Muslims require that for the new moon to determine the end of Ramadan (https://en.wikipedia.org/wiki/Ramadan#Eid))
The rest of that is hilarious. I have no interest to complicate things in those ways, but if you think those are good ideas, you should go for it! Propose them to your local government and try to get them to switch.
Everybody would have to know what location a meeting is scheduled in. “An hour after sunrise in London” would be the same for everyone, but if you also meetings “two hours after sunrise in Madrid” and “three hours after sunrise in Paris”, how much time there is between them will vary during the year.
Most people would have their clocks/watches/devices display regional time, or both regional and world time.
Things like business hours, school hours, meal times, regional transit schedules, and other things that mostly just involve coordinating with people in the region would use regional time.
For most people in a region, this would allow them to operate on a schedule that involves waking naturally to the brightening morning instead of using an alarm. It would also mean that all of the extra daylight hours that come with the summer would end up at the end of the day, instead of some of them going before you go to work or in more northern places even before you wake up.
So sunset at noon?
Because in case of local timezone policy changes, in the vast majority of cases the intention is for the future event to stay constant in the local timezone, and be changed in UTC / epoch. If for example you made the mistake of storing store opening hours in UTC and translate it to local time in the UI, you will be showing the wrong time.
For appointments, you need both the datetime and the location/timezone. In case of cross-timezone appointments, e.g. virtual meetings, if there are timezone policy changes the issue cannot be resolved without rescheduling the event for some participants.
(If your datetime library handles historical information in the DB correctly, that is!)
Unix epoch is known not to be good enough for some scientific applications :-/
Like, let's say you’re measuring the time between two events, and you’re logging a stream of them. If you use Unix timestamp, the timer will jump during a leap second.
This is because a day in Unix time is always exactly 86,400 “seconds”, but an actual civil day may be from 86,399 to 86,401 seconds. (It has never been 86,399 seconds, but it “could” be.)
So you should probably be using TAI. UTC is theoretically good enough but it is inconvenient to use because of the leap seconds. Unix time is a bit broken.
It is actually very easy to use TAI. You just need a GPS receiver. TAI is a fixed offset from GPS time (TAI = GPS + 19 seconds).
Why do we adjust time, and not geometry (given that geometry changes anyway because of shifting of tectonic plates)?
(By geometry I mean coordinates of objects like buildings, landmarks, etc.)
With your proposal, time handling would be slightly simpler, but every geographic coordinate everywhere would need to be tagged with a date to let you know which epoch it was relative to, or else you would get huge (in local terms) errors.
That’s more than 1000 times slower than leapsecond-related drift
We do, however, take plate movement in to account when determining positions of things on the surface. Geodesic coordinate systems periodically publish 'Datum' that are the result of new surveys of positions. In some places, such as Australia, the difference a decade can make is pretty large. Other places, not so much.
>A Date object can be created with an optional argument, the day of calendar reform as a Julian day number, which should be 2298874 to 2426355 or negative/positive infinity. The default value is Date::ITALY (2299161=1582-10-15).
There is an additional wrinkle to comment on, which is that not every country started their year on January 1. And when a country changed their year start to January 1 is often not the same as when they changed from Julian to Gregorian.
In the absence of more specific information, it is usual to assume that an unlabeled calendar reference is a Julian date reference (starting on January 1) until October 4, 1582 and a Gregorian date reference from October 15, 1582 onwards, with October 5-14, 1582 not existing. It should be noted that this calendar does not correspond to any actual calendar used by any polity in actual history that I am aware of, but it would tend to be less confusing than actual historical calendars.
In the Americas, the Julian or Gregorian calendar would have been adopted at time of European conquest. Similarly, in most of the rest of the world (which was conquered by Europeans at some time or another), civil administration would have switched to Gregorian when Europeans started administration, although this might not imply a change in local usage of calendar.
Islamic countries have had the most resistance to the Gregorian calendar, with Saudi Arabia not using it (de jure, although it was used in private industry de facto) until 2016 and Iran and Afghanistan still not using it.
At best, try to understand that if you do use something other than epoch time, you might have to record a bunch of stuff like what I mentioned.
Wrote a blog post about the most interesting things I found: https://medium.com/@florian_32814/date-time-526a4f86badb
1. The date 30 December 2009 never existed in Somoa and Tokelau https://www.bbc.com/news/world-asia-16351377
2. Until 1937, the Netherlands Timezone was a nice, even, GMT + 00:19:32.13 -- yes, the timezone offset was to a hundredth of a second. https://en.wikipedia.org/wiki/UTC%2B00:20