I place great value on time. I am one of those people who makes sure that all the clocks in my home are kept right on time. When it comes time to change clocks due to the absurd practice of Daylight Savings Time, I go round the previous night and do so so that there is no danger of my doing something at the wrong time the following day. I am baffled by those who are not bothered that their clocks are wrong and find even more incomprehensible those who deliberately set their clocks fast in order to help them avoid being late for things. Having to constantly mentally adjust the time makes no sense to me.
I also like to be punctual, feeling that being on time for meetings shows respect for the value of other people’s time. Hence I have reminders for meetings and other events that alert me to get wherever I need to on time. I set these times and alerts on my calendar and reminders on my computer that these then get synced with my phone and my iPad so that when the time comes, all three of them sound alerts.
But I noticed that they would not all go off at the same time, and the time differences would change slightly, even though they were all supposedly automatically linked to the official time. Curious, I looked into why that might be so. The official US time signal is from the National Institute of Standards Technology and can be seen here. That webpage also shows you the time on the device you are using to access the site and it showed some interesting results. While my phone time differed from the NIST time by much less than a second, my computer time was off by more, sometimes of the order of seconds, and on one occasion was off by nearly two minutes.
It appears that this is because while they both supposedly should be synchronized with NIST time, the phone gets its signal from cell phone towers while the computer gets its time signal from Apple through the wi-fi system. I am guessing that the phone time is directly from NIST while the Apple time is subject to time shifts that can happen as signals travel through the internet. Interestingly, different computers connected to the same wi-fi connection can have slightly different time lags. That I have no explanation for.
“Time is an illusion. Lunchtime doubly so.”
It’s my experience that cell time can be significantly out from immediate NTP queries, and out of the two I’d trust NTP time more. At the back end NTP is tied quite hard to multiple GPS and atomic clocks, whereas who knows what the hell the cell networks are doing. More to the point, the NTP protocol does serious statistical analysis of error sources and an NTP command-line client will *show you its working* so you can get a reasonable feel for how off it could be. (Usually sub-millisecond at your end, connected to a good network.)
However that only really works if you have a device that uses full NTP properly to sync its local timesource to real time. Device timers can be wildly and notoriously inaccurate, and while full NTP can to a certain extent account for that by calculating drift errors and compensating, if your drift isn’t reasonably constant (hopefully less common) you’re screwed, or if you just do a single query-and-set you’re going to drift, sometimes quite rapidly. Low-power modes that switch between the active system clock and the “battery backup” RTC can do strange and unpredictable things. Or if your device and/or the backend makes no pretence of doing anything remotely like NTP, who knows what error you’ll get.
(I find it deeply irritating that Android appears to have no current option to sync to a NTP server (particularly, a user-specified one). So your options are enter the time manually or use cell time, and it’s further irritating that entering the time manually can be more accurate.)
It’s my understanding that cell phone towers use gps for timekeeping purposes. I decided to do a test to see how close my android phone’s time is to gps derived time using an app, and what I found is that it’s about 2 seconds behind.
I toggled the option to automatically set the time off and then on again to see if I could get it to resync the time, and that brought the error down to the point that I can’t see it. It’s a little hard to be precise with my setup though, so some error may remain.
Make of this what you will, but it looks to me like cell phones are capable of quite accurate time syncs with cell phone towers, but they don’t sync often enough to counter their drift. Either that or the time sync is more frequent but inaccurate and I just got lucky with my manual sync.
I don’t know if they’ve improved, but in the past Apple shipped a default NTP configuration that would almost never achieve synchronization; they specified a very large minpoll value (12), presumably to minimize network traffic, but in consequence the capture window of the phase-locked loop algorithm was only about 7 PPM, so if the motherboard clock frequency was off by more than this (which is extremely common -- 10-50 PPM errors are normal and >50 is not rare), it would never lock on.
Mano, you could add one or more NTP servers to your macOS configuration:
https://www.ctrl.blog/entry/tutorial-macos-ntp-config.html
On Linux Mint, I have added the line “timedatectl set-ntp true” to ~/.profile to make sure NTP sync is on.
The only reason I need to be anywhere close to accurate about time is because of public transportation schedules, which are notoriously off both early and late. I used to worry excessively about being early to meetings because no one would ever wait for me if I was late. I still get unreasonably anxious about being late for doctor/dentist appointments, since I’m afraid they’ll give away my slot. Which, because public transportation, means I have to be 30-60 min early in case I miss a connection.
On a larger time scale, I honestly have trouble remembering how old I am. For about two years before I turned 30, when people asked my age I’d tell them I was 30, just to get me used to the idea. At 30, I was 32, at 32 I was 35, etc., and on through subsequent decades, until I became 60 when I was about 55. I’m currently well into my 70s now (though my driver’s license and the SSA emphatically beg to differ) and will probably be in my 80s or 90s next year.
Back in the 90s some of my nerd friends who worked at DEC made clocks that chimed with our NTP stratum-1 fuzzballs. It turns out that the trick is to forget how normal clocks are made. With a normal clock the problem is how to smoothly and accurately advance the hands. With a ln NTP clock the problem is how to know where the hands are and how to position them to where they should be. It’s more like a CNC robot than a clock. So you buy a regular clock and replace the mechanism with two stepper motors and the NTP engine. It was really cool; if there was a network outage or a power failure the clock would suddenly go “whoomp” and the hands were in new positions.
I have a clock in my studio that syncs to some kind of radio stratum-2 source. But it just has an LCD; that’s no fun unless it’s a nixie tube.
Marcus:
In my kitchen I have an “analog” clock that is controlled via DCF 77. Twice a year when switching to or from summer time, or when I have to put in new batteries, the hands race through the all-on-zero position to get to the correct time. That is certainly not as impressive as your “whoomp”. But it is quite weird when you are used to precise digital clocks.
… with seconds hand doing 60 rotations per “hour”, of course.
I was a software developer for The Boeing Company and in the course of working on a custom application that dealt with week-long airline schedules I was required to create the rules for converting arrival and departure times in three modes:
Local/Local (local time at both airports, which is how we see arrival/departure times when we book a flight)
UTC -- all times based on GMT. This is required to calculate how long the flight will take.
Local Based-On -- The user can select any airport in the world and base the flights on the time at that airport; that is, it is like UTC but potentially in a different time zone.
This would have been more or less straightforward except for the extremely complicating factor of daylight savings time (DST) going on and off at different times in different parts of the world. The DST effect had to be considered for every single action.
Suppose, for example, a flight departs from PHX (Phoenix, AZ), where there is never a DST offset, and while it is in the air DST changes at SEA (Sea Tac, near Seattle)? And so on. And on and on.
We had to invent an efficient way to update each airport’s DST information, which changed periodically. We had to deal with the fact that in a very few countries, DST went on and off more than once a year -- it would go on, and then a couple of months later, off for Ramadan, and then when Ramadan was over, it would go on again.
Anyway, on behalf of everyone whose life is complicated by DST, I would love to see DST eliminated everywhere forever.
Joel, surely a look-up table would do the job. Not that complicated.
re: John Morales, #12
We had a look up table for airports that included the UTC offset, e.g. without DST, Seattle is -8 UTC. We had a lookup table for DST changes. This table had 3 years of DST changes for all airports with the date and time of each DST event. We updated this table programmatically every 3 months and manually as needed. Sometimes, a country would decide to end DST and that would be reflected in a new data file. Also, we had to store historical DST changes because the analysts sometimes had to create “old” schedules to compare to new ones.
But a mere lookup table could not possibly have handled all the possible situations where DST calculations needed to take place, and there are far too many to fit into a comment but here is an example.
Suppose an airline sent a 12-month proposed schedule, let’s say 1/1/2020 through 12/31/2021. Our software allowed editing only on 7 day schedules at a time, and they always started on Monday and ended on Sunday, for reasons related to how the schedule had to display on a Gantt chart-type screen.
The user would load the long schedule and then specify a 7 day Monday-to-Sunday time period to cut out from the long schedule. The users created a rule that no schedule would be valid if DST changed at any airport during the schedule. Thus, the software had to check every single distinct airport in the schedule to ensure that during the week chosen, no changes (DST on or DST off) took place during that week.
Anyway, the complexity was due to the numerous business rules that had to be created in order to cover everything that might happen, like adding a new airport to an existing schedule, or adding a flight that departed within the 7 day schedule (late Sunday night) and landed on Monday, outside the 7 day window, at an airport whose DST did not change within the 7 day window but did change given the new, non-7-day arrival date/time.
Not only could a book be written about all the complexities of automating the time conversion, including DST checks, for the creation and editing of huge 7-day airline schedules, but effectively I and the programmers did write at least a book, a large one if you include all the test cases.
Long story as short as I can make it, we needed, for each schedule activity, to use the schedule table for the schedule dates, the flight table for the flight dates and times, the airport table to get the UTC offsets, and the DST table to find out exactly, to the minute, when DST changed for any airport.
Effectively, the code created a gigantic lookup table on the fly when any changes were made to a schedule but given the fact that each element of the virtual table needed to be maintained separately, a single enormous lookup table was, in practical terms, not possible.
Joel, thanks for the response. Made me smile — with you, not at you.
Did you remember to check the settings in your cameras? And whatever home appliances from microwave ovens to soldering irons that may have a clock these days…
Cell phones don’t use NTP. They get their time via control plane signals from the phone center, which has an accurate clock. Especially in networks that still support GSM, because it needs very accurate timing for its time slot management (8-way multiplex). Usually the center syncs with UTC, but it also has a rubidium clock as a backup. How often the phone gets sync’ed depends on many things.
“Having to constantly mentally adjust the time makes no sense to me.”
That’s crystal clear, because it’s not about mentally adjusting the time but the exact opposit -- it’s about deceiving yourself, thus having unexpectedly some more time.
“I also like to be punctual”
How unsurprising. However entire tribes of humans are incapable of being as punctual as you. I’m one of those. You show some lack of empathy on this topic.
In the end it’s simple. Your system works for you. Great. It still doesn’t work for me. So I need a few tricks to be in time for appointments. The principle is making sure you have some slack, whether concerning time, money or other things. In my case that means better ten minutes early than ten minutes late.
There’s a reason why, for any programming task involving time zone handling or even time in general, the usual advice is ‘find a library where somebody’s taken care of the details already and use that’. There are a lot of things that can go wrong.
I’ve had to deal with things like ‘how long is it until seven o’clock in the morning. Okay. Get current time as UTC and save it. Convert to local time. If the current time is after seven o’clock, add a day; in either case, then set the time to seven. Clear the DST flag in the time structure to mark it as undetermined. Convert back to UTC, trusting the library and the timezone database we have will know whether or not this is actually DST now and convert appropriately. Then subtract the saved current UTC time from the future time. That’s the length of the timeout we have to set.
And that’s on top of the fact that the people at head office who designed these things figured that having a system that just requested current time from an NTP server and hard-set the time at midnight every night was good enough. It might have been, if we weren’t trying to keep multiple devices on the same network synchronized to each other, and the RTCs on there weren’t cheap enough that they could be off by over a minute over the course of a day. In either direction, so two different devices could be over a minute off from each other, which made it difficult for timestamps generated on one to be handled on the other. (We ended up generating a system where they would all use full NTP to synchronize to an outside server which would also end up generating a ‘drift’ file to track how badly the RTC slid off-time so it could be corrected for later, with a backup of one ‘master’ device providing time to the others if the outside server was inaccessible, with a further fallback to ‘orphan’ mode if the master device wasn’t accessible either in which case the remaining devices would essentially vote amongst themselves.)
Accurate timekeeping is complicated.
Ridana @7: I used to not trust anyone over 30; but I passed 30 (hexadecimal) years ago. The good news is that I’m still in my mid-teens (sexagesimal).
Marcus @8: Nixie tubes! That brings back memories of Popular Electronics from my teens (decimal).
I really don’t understand the dislike of DST many have. I love it, but it occurs to me this may be because of where I live.
Long lingering summer evenings are just glorious in the south Pacific, who wouldn’t want it?
And who needs dark winter mornings?
I only have to manually adjust the clocks in my car (the cars itself and it’s stereo) as every other clock in my live is linked in some way to a time server -- and I don’t care if any is a teeny bit out.
And my job has often involved dealing with time issues (just last month I had an issue over UTC and Local times in a API I wrote -- mutter mutter bad database design…) but that’s nothing to hold against DST -- dealing with different languages and text encodings is worse.
I can work until 7pm and go practice the back nine on the way home (in summer).
Oh, and I forgot what I first meant to type -- Mano might like to buy clocks that sync directly to NIST signal broadcasts. I think I’ve seen such things for sale -- including as watches.
I tried to buy one for myself (some time ago) but it turns out NZ does not provide such a service.
re: jenorafeuer @17
Sounds like you have a real appreciation of the challenges that software developers face when dealing with time.
I didn’t even mention another problem with flight schedules: the international date line.
Joel Grant @21: ah, the date line. In my day job, I work on a system that schedules the movement of U.S. Mail. All too often people who should know better are adamant that a flight’s day count can’t be −1; so I need to point out, yet again, that a flight from, say, Guam (UTC+10) to Honolulu (UTC−10) can indeed arrive on the day before it departs. (This seems obvious to me, but lots of folks don’t get it…perhaps because they think of civil time as something physical rather than cultural.)
Disclaimer: “If this were my employer’s opinion, I wouldn’t be allowed to post it.” — Norman Diamond
Generally, as I understand it, but backed by some actual experience, most devices don’t check the time very often. If I want my not so smart phone to update the time I have to turn it off and then back on. Only then does it update. Similarly my PC only updates if I tell it to, using a program, or I do it manually. Otherwise these systems seem to chug along to their own internal clock independent of what the official time might be.
Some early PCs were prone to losing time when the internal battery maintaining BIOS and settings was getting weak. Forty years later I hear some PCs show the same behavior.
re: billseymour @22
Yes, it is quite possible to arrive before you depart, at least according to our timekeeping. Rather like the famous Ms. Bright:
There once was a woman named Bright
Who moved moved much faster than the speed of light
She went out one day
In a relative way
And returned the previous night.
lorn @#23,
Your comment would explain why the time differences between my devices and NIST keeps changing.
I had been under the impression that the synchronizing was going on almost continuously.