Date: Tue, 13 Oct 1998 17:47:19 +0200 From: Antoine Leca <Antoine.Leca@renault.fr> we can classify all the possible implementations in the following order: 1st, those implementations that know both UTC and TAI "perfectly".... 2nd, those implementations where the clock is UTC based and that have some knowledge about leap seconds, but where the famous table is not known to be correct. (1) and (2) actually form a sort of continuum, not a dichotomy, since no implementation can know UTC-TAI "perfectly" for all future timestamps. In other words, all implementations (even libtai, or Olson in "right" mode) operate with incomplete leap second tables; it's just that some tables are more incomplete than others. A simple way to allow both (1) and (2) is to have an API that makes the leap second table accessible. Once you do this, you can support all the implementation continuum between (1) and (2). 3rd, those implementations that only know about UT [without leap seconds]... 4th, worse, those ... that ... only know "some form of local time".... 5th, if it even exists, those that cannot figure what time is it. I doubt it really exists, but traditionnaly C handles them. My idea is that the API to be proposed should work OK and smoothly with all classes, with priority given to the highest class(es) where there are choices to make. That sounds reasonable, and an integer-timestamp API can do this, as does the struct xtime API. The main point is that everything (except the last class!) ends up as counts of seconds, and sometimes subseconds; but having to manage 2 functions for each functionnality seems too much for me; therefore I prefer something along the lines of struct taia or struct xtime. Sorry, you've lost me. If you want a simple integer timestamp, you don't need 2 functions for each functionality; it suffices to return a single count of subseconds. C9x has 64-bit integers, and 64-bit subsecond timestamps suffice for the vast majority of applications, so it's reasonable to return a single integer instead of returning a struct. Higher-quality implementations can return even longer timestamps (e.g. 128 bits) if there is need for this.