HN Explorer

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

16 points by vkoskiv ↗ HN
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)

18 comments

[ 0.23 ms ] story [ 50.2 ms ] thread
nilespotter
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
Same here. It looks good on my boxes. I think it's just the OP.
flockonus
A/B testing time, a timeless classic
vkoskiv
None of those servers is the specific one with the issue, though.
threeseed
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
Yes, but your code isn't specifically querying the timeserver I mentioned, which was 17.253.14.253.
DeRock 

    $ 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
`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
You're just querying time.apple.com, not 17.253.14.253 specifically.
drewolbrich
Random thought. Are you taking into account relativistic effects? What is your velocity relative to the Earth's inertial frame?
jldugger
How fast do you have to be moving for the relativistic effect to produce the same timestamp twice in a row?
ChristianGeek
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
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
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
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
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
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
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!