from Hacker News

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

by vkoskiv on 9/6/23, 8:59 PM with 18 comments

• by askbjoernhansen on 9/6/23, 10:00 PM

  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.

• by nilespotter on 9/6/23, 9:26 PM

  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

• by drewolbrich on 9/6/23, 9:35 PM

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

• by threeseed on 9/6/23, 9:32 PM

  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))

• by vkoskiv on 9/7/23, 6:36 AM

  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!

• by ChristianGeek on 9/6/23, 9:41 PM

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

• by DeRock on 9/6/23, 9:34 PM

      $ 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.

• by newman314 on 9/6/23, 9:50 PM

  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