The current calculation easily overflows if the local time is
around the unix epoch. I guess it isn't too unusual for
devices without RTC. Or, the battery is dead. Or, whatever.
This commit avoids the overflow by simply dividing everything by 2.
While more sophisticated and precise solutions are possible,
I feel that they are overkill for this simple implementation.
For example,
The unix epoch (1970) is 0x83aa7e8000000000 in
64-bit NTP timestamp. (1900-origin)
The timestamp now, as of writing this, is 0xe3cda16b00000000.
With the code before this commit, the offset will be:
(lldb) p (long long)((0xe3cda16b00000000 - 0x83aa7e8000000000) + (0xe3cda16b00000000 - 0x83aa7e8000000000)) / 2
(long long) $16 = -2295952992316162048
(lldb)
with the new code, it would be:
(lldb) p (long long)((0xe3cda16b00000000 / 2 - 0x83aa7e8000000000 / 2) + (0xe3cda16b00000 / 2 - 0x83aa7e8000000000 / 2))
(long long) $17 = 6927419044538613760
(lldb)
It's the correct offset from the unix epoch:
(lldb) p 6927419044538613760 >> 32
(long) $0 = 1612915435
(lldb)
spacetanuki% date -r 1612915435
Wed Feb 10 09:03:55 JST 2021
spacetanuki%
ca6907ccbe