Recent searches
Search options
Let's take a moment to remember the guy who made sure we don't have to change Every Goddamn Clock today, David L. Mills, creator of Network Time Protocol (NTP) who passed last year.
My wristwatch is synced to my phone, which is synced to the internet, which knows that time it is right now thanks to David Mills. Cheers to his memory 
@jjcelery well yes but NTP is not related to summertime is it. The clocks are right due to NTP but the time zone change is quite a separate thing. But I don’t know if he did work on tzdata stuff as well, maybe he did. Still, NTP is crucial.
@revk @jjcelery The tzutils and tzdata was cooperative work of the BSD UNIX community, with leadership, the heavy lifting and the majority of the code by Robert Elz (then of Australia's University of Melbourne).
Edit: I should add that the idea that an operating system should care about timezones and distinguish UTC and local time was the work of the UNIX authors Ken Thompson and Dennis Ritchie. Their idea was that the system time would be in UTC, and the time displayed to users would be the local time. The difference between the two kept in a numeric value in the user's TZ environment variable, which then informed the localtime() set of functions in the system library.
The key insight of tzutils was to reuse the TZ environment variable to contain the text of the user's nearby major city as a way of indicating the jurisdiction for the timezone. This was a user interface far more usable than an hours offset (Bell Labs) or the formal name of the timezone (System V).
The BSD tzdata and UNIX localtime system was so clearly the right answer that it has been retrofitted to other operating systems, such as Microsoft Windows.
@glent @revk @jjcelery and every time I see a tzdata package update being installed I look at the changelog https://launchpad.net/debian/+source/tzdata/+changelog to get my periodical dose of bizarre timezone-related political drama
Our webhoster moved our server to new hardware, and changed the timezone setting from local to UTC. That screwed up our software. Time stamps on files are off by 4 hours. Setting PHP date.timezone doesn't fix it. Now we have to do a code review to find why the app won't recognize the new TZ settings.
I seem to recall having to jigger the TZ function when we wrote the app. Maybe the webhost fixed a longstanding problem, but yeesh; time is hard.
@bobjonkman @cvtsi2sd @glent @jjcelery surely file timestamps are always UTC regardless? What o/s was that?
Some flavour of Red Hat. I suppose it's the locale settings that have changed. Where I used to see a file I touched at 13:00 local time have a 13:00 timestamp with ls, now I see a timestamp of 17:00. And it's similar with PHP time functions, now returning UTC values where they used to return local values.
1/2
@jasonkarns @jjcelery ok the relevance of “today” is surely summer time?
The time, UTC (or NTP) did *not* change from its normal sequence in any way today.
Devices did not sync to the summer time change due to NTP. They stayed right in UTC due to NTP. Very importance and worthy.
Summer time changes are not NTP related.
@jasonkarns @jjcelery the OP suggested a change of clocks “today” which is the day summer time happens for a lot of the non US northern hemisphere is down to NTP.
It is not. The need to “change clocks” is down to summer time, not NTP.
I am not trying to undermine the importance of NTP.
@jasonkarns @jjcelery I may be wrong, saying what the OP said, almost any day than today, would have made sense as a generic “these days”. And be sensible.
But to say “today” on the day summer time happens has a significant implication in to which I read the original post.
Maybe I was wrong in doing so?
@revk she never said the time changed “because ntp”.
She said that there is no need to manually change the clocks because ntp. Which is wholly true.
All I saw in your post is a “well actually” to something she never even said.
This is just my calm feedback to you. Which you are free to disregard or disagree with. I’ve said my piece.
@jasonkarns ok I still think making the point today, the day summer time comes in, was a summer time related post, and hence not NTP.
Maybe the OP can clarify.
She said that there is no need to manually change the clocks because ntp. Which is wholly true.Nope! That's the timezone database. NTP distributes UTC time.
Also worthy of mention is its current maintainer, Paul Eggert, with the backing of ICANN, and contributions from many many others.
[Insert relevant Tom Scott Computerphile video here.]
@nowster @jasonkarns @jjcelery That video is awesome!
@revk @nowster @jasonkarns @jjcelery Oh, /that/ video :-)
It captures the "aaarrgghh" vibe perfectly :-)
@nowster @revk @jasonkarns @jjcelery I really wish we could encode the current zoneinfo database into the GPS/NTP signal.
That way we would get an accurate UTC, an accurate location *and* an accurate zoneinfo by which to tell the local time.
The whole zoneinfo file is less than 300KB compressed (and probably much smaller if historical data is omitted) so it can be transmitted piecemeal over a relatively short time to fit into current ntp/gps frames.
Very useful for isolated devices such as watches, clocks, handheld GPS, vehicles, IoT, etc that don't have a good mechanism for getting zoneinfo updates but do have access to a GPS or NTP source.
@markd @nowster @revk @jasonkarns @jjcelery Uh likely not on GPS... The data rate is 50 bits/second there. Transfering "just 300KBytes" would take forever - even if you managed to free up e.g. 5% of bandwidth for that purpose (e.g. by dropping/slowing down other stuff like NAV), It would take more than 273 hours of continuous GPS transmissions to get the tzdata. And if you have Internet connection (usually needed for NTP), your OS can (and does) upgrade tzdata just fine anyway in just seconds...
@mnalis @nowster @revk @jasonkarns @jjcelery Ahh. Thanks for that. I never realised that the GPS pipe was *that* thin.
While it is true that most modern OSes include tzdata as part of their package distribution, this is much less true for IoT-type devices such as NTP/GPS clocks which often want you to manually enter DST offsets.
It's also the case that a lot of consumer-grade routers only offer minimal updates after release - which means their tzdata also becomes obsolete.
You could argue that such manufacturers should do better, but we all know how well tut-tutting sell-and-forget manufacturers works.
So anyhoo, that was the problem I was thinking about, but it's obviously stymied by GPS bandwidth, or lack thereof.
@markd @mnalis @nowster @jasonkarns @jjcelery there is a geostationary that is also used to augment GPS which maybe has more. Obvious slow data would be “current political boundaries”, and associated current, and upcoming, time zones for them. So you literally know what country/state you are in and what timezone(s) apply right now.
@revk @mnalis @nowster @jasonkarns @jjcelery The receiver knows that, but does the sender?
A sending satellite can presumably see close to 30-40% of the planet, so not really much of a discriminator, but I like your thinking.
@markd @mnalis @nowster @jasonkarns @jjcelery yeh the sender just sends whole planet data or at least its side. The receiver can then work out where it is.
@revk @mnalis @nowster @jasonkarns @jjcelery The other thing is that the tzdata diffs are tiny, so an infrequent full transmit of tzdata with frequent diffs could presumably fit into a pretty small transmission pipe.
@revk @mnalis @nowster @jasonkarns @jjcelery I think it's an interesting problem to model.
What do you think is a reasonably available bandwidth?
Heck, even if it takes a week for a device to build up a full tzdata, after that the updates are pretty tiny.
However, it's quite a tricky problem to know what to transmit so as to optimise for a full tzdata build vs a current tzdata diff across a universe of receivers.
Fortunately it's a very similar problem to a source control system, such as git so maybe we can get some clues from that?
@markd @revk @nowster @jasonkarns @jjcelery Not really, SBAS bandwidth is only marginally better (at 250bps, and obviously, you'd only get a percentage of that). Also, "diffs" and "git" ideas won't work, as #GNSS user-segment is unidirectional (i.e. receive-only) and you need bidirectional comms for them to work out what diffs are needed. And anyway, as IoT motto is least-effort, and they can't be bothered to do tzdata 'net update, I wouldn't hold much hope even if SBAS were to broadcast it...
@mnalis @markd @nowster @jasonkarns @jjcelery I think he means incremental updates not diffs and git as such.
You can engineer ways to have, over a long period, the whole data, but if constantly receiving you quickly have updates keeping your overall data up to date.
A lot of handling of resends in case data missed and so on, and a measure of “urgency” of change impacting frequency of resends.
@revk @markd @nowster @jasonkarns @jjcelery Well, you can prioritize data which you think will be needed more often (e.g. tzdata updates made in last month), but you still need to be sending all the data for those which were boxed or offline or whatever (and in fact, GPS already do such segmentation).
But since GPS is "Global NAVIGATION System", it is somewhat unlikely to send unrelated data such as timezones (any more than it is likely to send, say, general weather reports, news reports etc).
@markd @revk @nowster @jasonkarns @jjcelery In other words, it is economy problem, not a tech problem.
There is no financial incentive to do it in a proper way, and in fact, there is financial incentive to do it sloppy, so user will be forced to buy another "better" version later.
So the solution is also economical - refuse to buy (and lobby others to refuse to buy) #IoT which are #DefectiveByDesign. If your IoT was #FOSS, you and other hobbyist would add that, as incentive is there.
@mnalis @markd @nowster @jasonkarns @jjcelery all my IoT allows a tz string for your current timezone (and a link to a nice long list of them) but lacks any automated way to update that (yet).
@markd @revk @nowster @jasonkarns @jjcelery Another issue with using GPS to distribute tzdata is that many IoT devices are inside buildings, and #GNSS works really badly (or not at all) unless you have a line-of-sight to satellites. Another is that (unless your device already needs the GPS chip for its other functions) that it is unnecessary increasing hardware cost. And Internet-of-Things things are usually connected to Internet, so updating tzdata via Internet is literally single line of code.
@jjcelery hope it was really him and not the work of a female assistant he took credit for
@jjcelery interestingly enough, the only appliances I have to set twice a year are, the oven, the microwave (I somehow understand as they’re unconnected to anything) and the DAB/Internet radio (which sets the time via NTP but doesn’t bother about time zones) and the car (which is „data center on wheels“ modern).
@jjcelery he also invented Timezone Info Files? TIL.
![function Get-NtpTime {
param ($Server = "pool.ntp.org")
$NtpData = New-Object byte[] 48
$NtpData[0] = 0x1B # NTP-Request
$UdpClient = New-Object System.Net.Sockets.UdpClient
$UdpClient.Connect($Server, 123)
$UdpClient.Send($NtpData, $NtpData.Length)
$EndPoint = New-Object System.Net.IPEndPoint ([System.Net.IPAddress]::Any, 0)
$NtpData = $UdpClient.Receive([ref]$EndPoint)
$UdpClient.Close()
# Umrechnung in eine lesbare Zeit
$IntPart = [BitConverter]::ToUInt32($NtpData[43..40], 0)
$FracPart = [BitConverter]::ToUInt32($NtpData[47..44], 0)
$UnixTime = $IntPart - 2208988800 # NTP-Zeit startet 1900, Unix-Zeit startet 1970
$DateTime = (Get-Date "1970-01-01 00:00:00").AddSeconds($UnixTime)
return $DateTime
}
Get-NtpTime -Server "pool.ntp.org"](https://cdn.masto.host/mastodonie/cache/preview_cards/images/021/830/135/original/dd3c5686fa79eede.png "function Get-NtpTime {
param ($Server = \"pool.ntp.org\")
$NtpData = New-Object byte[] 48
$NtpData[0] = 0x1B # NTP-Request
$UdpClient = New-Object System.Net.Sockets.UdpClient
$UdpClient.Connect($Server, 123)
$UdpClient.Send($NtpData, $NtpData.Length)
$EndPoint = New-Object System.Net.IPEndPoint ([System.Net.IPAddress]::Any, 0)
$NtpData = $UdpClient.Receive([ref]$EndPoint)
$UdpClient.Close()
# Umrechnung in eine lesbare Zeit
$IntPart = [BitConverter]::ToUInt32($NtpData[43..40], 0)
$FracPart = [BitConverter]::ToUInt32($NtpData[47..44], 0)
$UnixTime = $IntPart - 2208988800 # NTP-Zeit startet 1900, Unix-Zeit startet 1970
$DateTime = (Get-Date \"1970-01-01 00:00:00\").AddSeconds($UnixTime)
return $DateTime
}
Get-NtpTime -Server \"pool.ntp.org\"")
@jjcelery but it's also worth cursing the memory, and spitting on the graves, of George Hudson and William Willett, who created the whole stupid mess in the first place.
Not one microsecond of time has ever been saved in all the hundred and eight years British people have been compelled to tinker semi-annually with their clocks in the hope of saving some. In the same period, however, thousands of people have been killed by the uptick in road crashes around the changes.
@jjcelery
GNU David Mills
@jjcelery I'd also like to pillory the stupid fuck who came up with Daylight Saving Time in the first place.
Eveline Sulman 
@jjcelery Let's take a moment to sincerely hope for a decision in the EU to stop this nonsense. This week, I will feel tired on Monday and Tuesday. Then sick on Wednesday. I might skip the meetings on Thursday because I have to sleep so that I will feel more or less normal on Friday.
@jjcelery NTP might be one of the most underrated technologies at the very base of our contemporary civilisation. Right there with container logistics and long distance telephone lines.
@jjcelery I really really appreciated NTP. I spent several days diagnosing a 'missing data' problem that had recently appeared on a very critical HA system. I found that the clock on one of the involved machines was off by several seconds. I, very politely, asked the admins to run NTP on all the machines involved.
Amazing! Data loss issue went away.
Thank you David Mills.
@jjcelery "Of course, it would be impractical to have all clocks on the planet synchronize directly with an atomic clock."
In the early '90s I worked with a guy whose dad worked at Intel. The guy I worked with wore a watch that would periodically sync itself to an atomic clock signal. My impression was that it did it by connecting to a cell service but thinking about it now if that's how it did it, its range must have been really limited given the tech of the day.
At any rate I don't think they were commercially produced, but there was a time when there was at least one demonstration product that embraced the impractical approach.
@theotherbrook @jjcelery
It probably used a Long Wave radio signal. Most digital wall and desk clocks (with sync) use the same standard.
@dec23k @jjcelery Yeah, that makes sense.
Maybe I should have thought of that at the time, since I'd previously spent a week in the field with my geologist father trying to use a device that purported to map subterranean metal deposits by triangulating off VLF stations used for submarine navigation. We could only get tuned to two stations though so in the end we just did some good ol' rod and chain surveying. I had some familiarity with the stuff being broadcast at those frequencies but I wasn't as curious about that watch as I would have been just a couple years later.
@jjcelery The fault tolerance in NTP is a spectacular robust design. It's a thing everyone should study. It's probably not perfect but one needs to remember how long ago the protocol was created and the order of magnitude in changes that computing has undergone in that timeframe. Given that we're still using it decades later, says ago you need to know.
@jjcelery NTP is wonderful, and it's how I resolved my "am I late for work?" panic this morning--set Android using NTP ("AtomicClock: NTP Time" app by author Timo Partl) and then set watch from my phone.
(watch set itself forward by 45 mins overnight, which was unexpected!)
@jjcelery Thank you to remember him. Big guy. I hope he is n the sky, we all have the good time.
@jjcelery but why the absolute **** are we continuing this temporary WW1 arrangement long after its theoretical justification (convenience for harvesting in farming) has become irrelevant, and long after we know that health, safety and wellbeing of the population is jeopardised by it?
@jjcelery NTP has literally nothing to do with that. The offset is applied locally.
@jjcelery Also: The Fuzzball.