3 ms·

time.apple.com (17.253.14.253) is returning the wrong date and time

16 points by vkoskiv 3y ago

Hey HN. Is this just me? I was doing some late night hacking on a System 6 NTP client I'm working on, and I couldn't figure this out, until I looked at the tcpdump log and observed the date coming in wrong from Apple's timeserver. I can reproduce this with `ntpdate` and the SerenityOS `ntpquery` as well, so it can't be my code. I always get this same reference timestamp back: 3889764561.575988850 (2023-04-06T10:09:21Z)

nilespotter 3y ago
I think it's just you # ntpdate -q time.apple.com server 17.253.82.253, stratum 1, offset +0.044020, delay 0.06635 server 17.253.82.125, stratum 1, offset +0.045065, delay 0.06586 server 17.253.16.125, stratum 1, offset +0.044869, delay 0.05829 6 Sep 15:25:18 ntpdate[65639]: adjust time server 17.253.16.125 offset +0.044869 sec
- EvanAnderson 3y ago
  Same here. It looks good on my boxes. I think it's just the OP.
  - flockonus 3y ago
    A/B testing time, a timeless classic
- vkoskiv 3y ago
  None of those servers is the specific one with the issue, though.
threeseed 3y ago
This works fine for me: import socket import struct import time NTP_SERVER = "time.apple.com" NTP_PORT = 123 TIME1970 = 2208988800 client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) data = b'\x1b' + 47 \* b'\0' client.sendto(data, (NTP_SERVER, NTP_PORT)) data, addr = client.recvfrom(1024) if data: t = struct.unpack('!12I', data)[10] t -= TIME1970 print("Current time:", time.ctime(t))
- vkoskiv 3y ago
  Yes, but your code isn't specifically querying the timeserver I mentioned, which was 17.253.14.253.
DeRock 3y ago
$ sntp -n 1 time.apple.com | grep t1 t1: E8A36E57.9BB5D031 (3903024727.608242999) # Subtract delta from unix time epoch to NTP epoch # NTP epoch is January 1, 1900, Unix epoch is January 1, 1970 $ date -r $(expr 3903024727 - 2208988800) Wed Sep 6 14:32:07 PDT 2023 Works for me.
- askbjoernhansen 3y ago
  `t1` comes from your computer, so since I told OP they were looking at the wrong thing I have to point you out did as well. :-)
- vkoskiv 3y ago
  You're just querying time.apple.com, not 17.253.14.253 specifically.
drewolbrich 3y ago
Random thought. Are you taking into account relativistic effects? What is your velocity relative to the Earth's inertial frame?
- jldugger 3y ago
  How fast do you have to be moving for the relativistic effect to produce the same timestamp twice in a row?
ChristianGeek 3y ago
Perhaps you have just stumbled upon a way to make time stand still, in which case you’ll never see any of these replies.
newman314 3y ago
Just took a look at time across Cloudflare, System76, Microsoft, Apple, Facebook, AWS and NIST. Looks like Facebook has the best time at this point. MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^- time.cloudflare.com 3 6 37 5 -2135us[-2132us] +/- 18ms ^- time.cloudflare.com 3 6 37 3 -1514us[-1511us] +/- 18ms ^- virginia.time.system76.c> 2 6 37 4 -2250us[-2247us] +/- 54ms ^- ohio.time.system76.com 2 6 37 2 -4525us[-4522us] +/- 42ms ^- oregon.time.system76.com 2 6 37 3 +742us[ +745us] +/- 30ms ^? 52.148.114.188 3 6 37 3 -544us[ -541us] +/- 124ms ^? defra1-ntp-004.aaplimg.c> 1 6 37 3 -1297us[-1294us] +/- 79ms ^? time4.facebook.com 1 6 37 4 -73us[ -71us] +/- 36ms ^? ec2-54-81-127-33.compute> 4 6 37 2 -369us[ -366us] +/- 35ms ^? time-a-wwv.nist.gov 1 6 17 42 +5816us[+5858us] +/- 24ms
- askbjoernhansen 3y ago
  It doesn't really tell you that, not yet. You didn't wait long enough for chronyd to decide. All your output here shows is that all the servers are equally reachable since you started chronyd (very recently, except the NIST server) and the Facebook server had the most similar time to what is on your system. For the aaplimg service, you'd be better off using the general hostname than a specific server that appears to be on a different continent than you.
  - newman314 3y ago
    So I just reran and here are the numbers. Outside of my local NTP servers, time.facebook.com still seems to be good. MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 0000000000000000 1 6 377 72 -1724ns[-3212ns] +/- 134us ^+ 111111111111111111 2 6 377 70 +13us[ +13us] +/- 215us ^+ 222222222222222 1 6 377 68 -1064ns[-1064ns] +/- 135us ^- time.cloudflare.com 3 10 377 513 -1511us[-1525us] +/- 18ms ^- time.cloudflare.com 3 10 377 914 -2347us[-2375us] +/- 18ms ^- virginia.time.system76.c> 2 10 377 620 -987us[-1012us] +/- 54ms ^- ohio.time.system76.com 2 10 377 464 -2672us[-2685us] +/- 43ms ^- oregon.time.system76.com 2 10 377 511 +1921us[+1906us] +/- 30ms ^? 52.148.114.188 3 10 377 67m +7902us[+7908us] +/- 141ms ^? defra1-ntp-004.aaplimg.c> 1 10 377 563 +292us[ +275us] +/- 83ms ^? time4.facebook.com 1 10 377 468 -203us[ -216us] +/- 36ms ^? ec2-54-81-127-33.compute> 4 10 377 424 -887us[ -900us] +/- 35ms ^? time-a-wwv.nist.gov 1 10 377 492 +6515us[+6500us] +/- 25ms I do use the generic time.apple.com entry along with other "official" names in my chrony.conf. I think my use of ODoH may be the reason why I'm getting systems further than expected. Will have to dig into it a little further. pool time.cloudflare.com iburst nts maxsources 2 server virginia.time.system76.com iburst nts server ohio.time.system76.com iburst nts server oregon.time.system76.com iburst nts server time.windows.com iburst server time.apple.com iburst server time.facebook.com iburst server time.aws.com iburst server time.nist.gov iburst
askbjoernhansen 3y ago
You are mixing up the 'reference time' and the bits of the NTP packet you are supposed to use to actually set the time. The reference time is not it.
- vkoskiv 3y ago
  You are correct, it seems! Still weird though why Apple's reference timestamp on this particular server is so far off? Thanks for pointing this out!
vkoskiv 3y ago
So as askbjoernhansen helpfully pointed out, I can't actually just look at the reference timestamp and use that. I was a bit hasty when putting this together, I didn't initially read the spec, I just looked at the NTP response in tcpdump, saw that "reference timestamp" looks about right, and went with that. I now know how to compute the actual offset I'm supposed to use, and I'll implement that instead. That computation doesn't involve the reference timestamp. Still curious why the reference timestamp on this particular timeserver is stuck at that particular time, though. If anyone knows anything about this, do let us know!

16 points by vkoskiv 3y ago

nilespotter 3y ago

I think it's just you # ntpdate -q time.apple.com server 17.253.82.253, stratum 1, offset +0.044020, delay 0.06635 server 17.253.82.125, stratum 1, offset +0.045065, delay 0.06586 server 17.253.16.125, stratum 1, offset +0.044869, delay 0.05829 6 Sep 15:25:18 ntpdate[65639]: adjust time server 17.253.16.125 offset +0.044869 sec

EvanAnderson 3y ago
Same here. It looks good on my boxes. I think it's just the OP.
- flockonus 3y ago
  A/B testing time, a timeless classic
vkoskiv 3y ago
None of those servers is the specific one with the issue, though.

threeseed 3y ago

This works fine for me: import socket import struct import time NTP_SERVER = "time.apple.com" NTP_PORT = 123 TIME1970 = 2208988800 client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) data = b'\x1b' + 47 \* b'\0' client.sendto(data, (NTP_SERVER, NTP_PORT)) data, addr = client.recvfrom(1024) if data: t = struct.unpack('!12I', data)[10] t -= TIME1970 print("Current time:", time.ctime(t))

vkoskiv 3y ago
Yes, but your code isn't specifically querying the timeserver I mentioned, which was 17.253.14.253.

DeRock 3y ago

$ sntp -n 1 time.apple.com | grep t1 t1: E8A36E57.9BB5D031 (3903024727.608242999) # Subtract delta from unix time epoch to NTP epoch # NTP epoch is January 1, 1900, Unix epoch is January 1, 1970 $ date -r $(expr 3903024727 - 2208988800) Wed Sep 6 14:32:07 PDT 2023 Works for me.

askbjoernhansen 3y ago
`t1` comes from your computer, so since I told OP they were looking at the wrong thing I have to point you out did as well. :-)
vkoskiv 3y ago
You're just querying time.apple.com, not 17.253.14.253 specifically.

drewolbrich 3y ago

Random thought. Are you taking into account relativistic effects? What is your velocity relative to the Earth's inertial frame?

jldugger 3y ago
How fast do you have to be moving for the relativistic effect to produce the same timestamp twice in a row?

ChristianGeek 3y ago

Perhaps you have just stumbled upon a way to make time stand still, in which case you’ll never see any of these replies.

newman314 3y ago

Just took a look at time across Cloudflare, System76, Microsoft, Apple, Facebook, AWS and NIST. Looks like Facebook has the best time at this point. MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^- time.cloudflare.com 3 6 37 5 -2135us[-2132us] +/- 18ms ^- time.cloudflare.com 3 6 37 3 -1514us[-1511us] +/- 18ms ^- virginia.time.system76.c> 2 6 37 4 -2250us[-2247us] +/- 54ms ^- ohio.time.system76.com 2 6 37 2 -4525us[-4522us] +/- 42ms ^- oregon.time.system76.com 2 6 37 3 +742us[ +745us] +/- 30ms ^? 52.148.114.188 3 6 37 3 -544us[ -541us] +/- 124ms ^? defra1-ntp-004.aaplimg.c> 1 6 37 3 -1297us[-1294us] +/- 79ms ^? time4.facebook.com 1 6 37 4 -73us[ -71us] +/- 36ms ^? ec2-54-81-127-33.compute> 4 6 37 2 -369us[ -366us] +/- 35ms ^? time-a-wwv.nist.gov 1 6 17 42 +5816us[+5858us] +/- 24ms

askbjoernhansen 3y ago
It doesn't really tell you that, not yet. You didn't wait long enough for chronyd to decide. All your output here shows is that all the servers are equally reachable since you started chronyd (very recently, except the NIST server) and the Facebook server had the most similar time to what is on your system. For the aaplimg service, you'd be better off using the general hostname than a specific server that appears to be on a different continent than you.
- newman314 3y ago
  So I just reran and here are the numbers. Outside of my local NTP servers, time.facebook.com still seems to be good. MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 0000000000000000 1 6 377 72 -1724ns[-3212ns] +/- 134us ^+ 111111111111111111 2 6 377 70 +13us[ +13us] +/- 215us ^+ 222222222222222 1 6 377 68 -1064ns[-1064ns] +/- 135us ^- time.cloudflare.com 3 10 377 513 -1511us[-1525us] +/- 18ms ^- time.cloudflare.com 3 10 377 914 -2347us[-2375us] +/- 18ms ^- virginia.time.system76.c> 2 10 377 620 -987us[-1012us] +/- 54ms ^- ohio.time.system76.com 2 10 377 464 -2672us[-2685us] +/- 43ms ^- oregon.time.system76.com 2 10 377 511 +1921us[+1906us] +/- 30ms ^? 52.148.114.188 3 10 377 67m +7902us[+7908us] +/- 141ms ^? defra1-ntp-004.aaplimg.c> 1 10 377 563 +292us[ +275us] +/- 83ms ^? time4.facebook.com 1 10 377 468 -203us[ -216us] +/- 36ms ^? ec2-54-81-127-33.compute> 4 10 377 424 -887us[ -900us] +/- 35ms ^? time-a-wwv.nist.gov 1 10 377 492 +6515us[+6500us] +/- 25ms I do use the generic time.apple.com entry along with other "official" names in my chrony.conf. I think my use of ODoH may be the reason why I'm getting systems further than expected. Will have to dig into it a little further. pool time.cloudflare.com iburst nts maxsources 2 server virginia.time.system76.com iburst nts server ohio.time.system76.com iburst nts server oregon.time.system76.com iburst nts server time.windows.com iburst server time.apple.com iburst server time.facebook.com iburst server time.aws.com iburst server time.nist.gov iburst

askbjoernhansen 3y ago

You are mixing up the 'reference time' and the bits of the NTP packet you are supposed to use to actually set the time. The reference time is not it.

vkoskiv 3y ago
You are correct, it seems! Still weird though why Apple's reference timestamp on this particular server is so far off? Thanks for pointing this out!

vkoskiv 3y ago

So as askbjoernhansen helpfully pointed out, I can't actually just look at the reference timestamp and use that. I was a bit hasty when putting this together, I didn't initially read the spec, I just looked at the NTP response in tcpdump, saw that "reference timestamp" looks about right, and went with that. I now know how to compute the actual offset I'm supposed to use, and I'll implement that instead. That computation doesn't involve the reference timestamp. Still curious why the reference timestamp on this particular timeserver is stuck at that particular time, though. If anyone knows anything about this, do let us know!