On 29 January 2011 15:20, Tom Van Baak <[email protected]> wrote: >>> Your java class going to provide the true TAI, the true UTC, >>> and the a user-friendly (smoothed, non leap second) version >>> of UTC, right? If so, what name do you plan to use for that >>> latter time scale? Some OS's use words like "system time" >>> or "gmtime". >> >> I call it the "UTC-SLS" time-scale. See new thread on Instant. > > Would it be possible to expose to the user a UTC-like class > that is guaranteed to be within 1 second of true UTC and is > guaranteed to have 86400 seconds a day (no leap seconds) > but leave the implementation details to the guys who write the > class?
JSR-310 is both a spec and an implementation (well ThreeTen is strictly speaking the implementation, but thats a detail). I do not expect anyone else to implement the spec in *Java* code. However, you are correct that the spec will be implemented by multiple independent people to implement the associated clock (probably in C), and they may be limited in terms of what they have access to. Lets say we define a new time scale FDS which is the fixed-day-subdivisions scale where days always have 86400 subdivisions (commonly known as seconds) but there is no fixed mapping to TAI of SI seconds other than a restriction that the length of an FDS day must not be more than 0.9 SI seconds from the mean solar day. Well, thats fine as a few words, but its very wishy washy in practice. If one implementation uses smoothing over the whole day, and another uses UTC-SLS (both valid implementations of the FDS spec), what happens when those two implementations communicate? A timestamp may be out. Now while that may happen anyway, making it more likely doesn't seem like moving the world forwards. (And I doubt FDS would achieve consensus as a definition on this list or standards bodies) Choosing UTC-SLS as the only approach is dictatorial, but lays down a marker to others. It puts pressure on OS writers to provide accurate UTC or UTC-SLS, which seems to me to be a good thing. > Given that, the various ports of this class can adapt to whatever > hardware or OS using the smoothing algorithm of their choice; > one that fits. Under the hood it could be the double long 59 > method or the double 00 method (both a form of SLS(1)), or > SLS(60), or SLS(1000), or SLS(86400). Further Michael can > use UT1 for his implementation of the class, and still meet the > spec ;-) Sounds nice, but I think that way leads to more confusion, not less. I could define as "an 86400 subdivision day where any UTC leap second must be resolved to subdivisions by smoothing covering a period starting no earlier than 23:00 and finishing at midnight where a smoothing factor of 1000 seconds is preferred". That definition gives implementors some flexibility while avoiding complete separation of implementation strategies. But I'm not sure its really a helpful direction to go. > But if you're trying to make an easy time class for millions of > people to use, 86400 is the kind of number they want to see > in the class description. Not worrisome times like 23:43:21. In that I agree. I might move the whole UTC-SLS section just to the UTCInstant class, with simply a reference from Instant. Most users don't want to see such a complicated explanation, as they might think they need to understand it! > One problem with the UTC-SLS draft proposal is that is stands > only as a reaction to UTC, as UTC is currently defined. If/when > leap seconds go away the entire premise of UTC-SLS and its > hardcoded milli-leaps vanishes, leaving it an awkward, though > creative, nop of history. True. But I'd still need some way to describe time between 1972 and the mythical date when leap seconds stop. And I'd still need a smoothing for that. (As I've said before, stopping leap seconds now isn't helpful as it adds yet another mapping/complication, rather than removing one) Nevertheless, this is an intriguing approach to the class. Stephen _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
