Date: Sat, 05 Sep 1998 21:40:27 +0100 From: Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> I prefer sound and consistent semantics here, and I think they are only possible with minute UTC offsets. The implementation that I'm typing this message on (Solaris 2.6) has time zones that are not at integral offsets from UTC (e.g. Liberia until 1972). This implementation does not have any semantic problems with leap seconds that are not the last second in a localtime minute, since it does not support leap seconds. I don't think that the C standard should disallow this type of implementation, which is fairly common in practice. 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? Historical practice was to specify UTC offsets only to the nearest second. For example, I believe that the legal definition of Paris Mean Time (used as the basis for official time in France until 1978) was 9 minutes and 21 seconds ahead of Greenwich Mean Time. I've never seen any records of more-precise UTC offset specifications; I don't think the standard needs to support this. I feel the KISS principle dictates minute offsets here. Isn't it simpler to follow widespread existing practice (POSIX.1, Linux, Solaris, SVR4, BSD, etc., etc.), which uses second offsets? 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. I don't see why this is the only reasonable solution; it's akin to assuming that we do not fall into the 31st day of a month, since not all months have 31 days. GNU mktime does not make this assumption; if you add 1 to 23:59:59, you'll get 23:59:60 if that leap second happens to exist and if the host support leap seconds. So there's an existence proof that leap seconds can be handled properly. I don't think the C standard needs to _require_ proper handling of leap seconds; but the standard should not _disallow_ it.
It would be a good idea to use a common prefix for the structure elemen= ts (xtm_nsec, xtm_sec, etc.).
I never understood what these common prefixes are good for. I believe that they were put in for historical reasons. In very old versions of the C compiler, all structure members lived in the same name space. Nowadays this original motivation is not important, but the tradition lives on in some places. Personally, I don't think the xtm_ is needed, but I don't care too much one way or the other.