<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 13, 2015 at 2:52 PM, <span dir="ltr"><<a href="mailto:random832@fastmail.us" target="_blank">random832@fastmail.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Do we know if other packages like ntp are actually able to handle the<br>
"right" situation correctly, even _with_ the appropriate UTC zone<br>
installed? Nevermind the fact that no-one actually uses<br>
time2posix/posix2time, and there's been no real effort to identify<br>
programs that need it (any tar archiver would be an example) and<br>
evangelize these functions to those projects. Maybe it's time to stop<br>
shipping these files entirely, and ask some serious questions about the<br>
future of leap second support.<br>
<br>
I think the core problem is that the use of a numeric time_t-like format<br>
for representing leap-aware timestamps is an attractive nuisance in a<br>
world where POSIX mandates a non-leap-aware version. If anything, I<br>
think the most likely conclusion is that these maintainers are likely<br>
trying to maintain backwards compatibility for people who do broken<br>
things like TZ=right/whatever not knowing any better.<br>
</blockquote></div><br></div><div class="gmail_extra">Back in the late '80s, when this stuff was first written, I ran a system using a "right clock" and found that it required surprisingly few time2posix()/posix2time() calls to (appear to) work. One such call was certainly in NTP, and there were a few others in programs that attempted to do time_t arithmetic (like cron). Raw timestamps stored in file systems and sent in other network protocols did not appear to cause major issues, but this was before the days of widespread interconnection. I'm sure things are infinitely worse now.</div><div class="gmail_extra"><br></div><div class="gmail_extra">My intent was certainly to demonstrate an alternative to the POSIX definition, in which clocks did not need to be adjusted over leap seconds and time_t's where more opaque. With equal certainty I conclude that it didn't catch on.</div></div>