"Joseph S. Myers" wrote on 1998-09-04 20:38 UTC:
It would be a good idea to use a common prefix for the structure elements (xtm_nsec, xtm_sec, etc.).
I never understood what these common prefixes are good for. What is the reason for calling struct elements tm_sec, tm_min, etc. instead of sec, min, etc.? I find them rather strange and ugly.
int offset; // minutes east off UTC
Seconds might be better.
I think it was a error to allow seconds in the TZ offset in POSIX.1, and I would like to avoid copying such intellectual accidents of the POSIX authors into this proposal. If a local time zone really were defined to have a fixed offset relative to UTC that is not an integral multiple of minutes, then bizarre things would happen near UTC leap seconds. If some politician really should decide that his local time is say 5h 7m 42s behind UTC, then we can't handle this appropriately anyway, and then specifying -04:08 is as acceptable in this silly situation as would be anything else. You would never use such an esoteric time zone for precision applications anyway! Historic time zones with a non-minute offset relative to GMT (UT0, UT1, UT2, etc.) are not defined relative to UTC, and therefore we shouldn't IMHO create the false impression that we could support these with second precision. I prefer sound and consistent semantics here, and I think they are only possible with minute UTC offsets. If you think that civil time zones defined relative to UT1 will become fashionable one day, then why on the other side should we allow only second resolution and not add nanoseconds in addition? I feel the KISS principle dictates minute offsets here.
What is appropriate in canonicalisation if the seconds value is 60? The natural expectation is that this causes the minutes to increase unless we are at a leapsecond - but this requires a leapseconds table. The alternative, ending up with nanoseconds of 10^9 in the struct xtime, seems unfortunate.
I have been thinking about this, and the only reasonable solution I can think of is that we always assume that we do not fall into a leap second. After all, this is only wrong with a probability of less than 1 in 40 million. I cannot think of an application where this would matter. Note that MANY of the previously necessary applications of mktime vanish by the simple fact that we now introduce a well-defined encoding for TIMEOPT_UTC. You do not have to abuse mktime any more to add an hour in a portable way to a time_t. If you care mainly about time intervals and not about UTC, then you should use TIMEOPT_MONOTONIC, which gives you a leapsecond free time scale (which on implementations with a battery clock like every PC has one can even survive across powerdowns). An equivalent of difftime is not necessary in this API for the very same reason. Just don't abuse UTC to calculate time intervals. Thanks a lot, also for your very good other comments. I'll try to consider them in the next draft. Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>