Of course, if you're adding/subtracting you need to know what your policy is not just for leap seconds but for DST -- a much more common and substantial problem. In general you shouldn't add/subtract seconds in an attempt to calculate days/months/years, but should convert to/from some sort of calendar notation, letting the conversion handle such oddities.
(And one hopes that no one's relying on Android accuracy to run a nuclear reactor.) (Though actually medical devices and industrial controls are fairly happy with the Unix clock, since they mostly just want to measure time intervals, not calculate wall time accurately.) (And I've always felt that a serious mistake was made to add leap seconds, vs define the second a hair longer and subtract seconds. Handling an 61 second minute is far trickier for a computer than handling a 59 second minute.) On Dec 29, 3:00 pm, Bob Kerns <[email protected]> wrote: > Sort and compare, mostly true -- but fail if you try to deal with a > leap second. At least that's relatively rare. > > Subtract? No. Fails if a leap second falls between the two times. This > is much a much more common case. > > In either case, your software can malfunction anew on every leap > second. > > Do you want medical device, or industrial control, or flight > navigation system, to hiccup on every leap second? Sometimes a second > is an enormous error. > > On Dec 29, 9:05 am, DanH <[email protected]> wrote: > > > It should be pointed out that it doesn't matter (much) what time > > reference is used, so long as it's used consistently, and all > > conversion algorithms to/from the reference form understand its > > details. So long as a consistent reference is used dates will sort > > and compare correctly. > > > On Dec 28, 9:41 pm, Bob Kerns <[email protected]> wrote: > > > > I didn't realize until now that POSIX absolutely FAILED on this. Every > > > description I've seen of this time indicates either that it's number > > > of seconds since January 1, 1970, or that it's UTC -- but it is, in > > > fact, neither. > > > > ((Bangs head on keyboard at one second intervals, carefully skipping > > > over leap seconds)). > > > > I'm torn between thanking you for pointing this out, and screaming! > > > Both, I guess. I guess it shows how poorly people -- even people on > > > standards committees who OUGHT to know better -- understand time. > > > > See the Sun Javadoc for the wiggle room Java allows, based on whatever > > > imperfections the underlying OS has on this > > > score:http://download.oracle.com/javase/6/docs/api/java/util/Date.html > > > > The Android SDK documentation, on the other hand, is pathetically > > > silent on the matter. > > > > The Wikipedia article on Unix time indicates that there's discussion > > > of dropping leap seconds, and letting civil time drift. I guess > > > eventually, "noon" will lose whatever vestiges of meaning it has now. > > > > This has been a sore point for me for decades. Timekeeping with > > > sufficient accuracy (i.e within seconds) for celestial navigation is > > > one of the greatest scientific endeavors, occupying some of science's > > > best minds over centuries, culminating in the Longitude Prize, offered > > > in 1714 and ultimately won in 1773. > > > > The earth rotates one nautical mile at the equator every 4 seconds, so > > > even one second of error in time contributes significant error in > > > position. > > > > I have in my possession the 6 volumes of Sight Reduction Tables > > > published by the US Defense Mapping Agency. 6 volumes of tables of > > > numbers for accurate calculation of spherical trigonometry with > > > detailed attention to accuracy, carefully described procedures for > > > calculation, down the the model of computer (IBM 1401) used to perform > > > the calculations. And yes, I used to use them. When your personal > > > safety, and of your crew, depends on accurate time, it gives you a > > > different perspective on the matter! > > > > Accurate timekeeping is no less important in computer systems, where > > > properly sequencing internal and external events is often critical -- > > > and sometimes involves life safety. Yet generations of programmers and > > > system administrators alike have refused to be bothered with accurate > > > timekeeping. > > > > I guess I'll go protest by setting all my clocks to UTC. (I've used > > > exclusively 24-hour time for almost 40 years, and am used to doing the > > > conversion to/from UTC, so it won't bother me!) > > > > On Dec 27, 9:12 pm, Steve Allen <[email protected]> wrote: > > > > > On Dec 26, 11:39 pm, Kostya Vasilyev <[email protected]> wrote: > > > > > > With all due respect, there is a much easier way. > > > > > > Java date/time stamps are internally represented by "long" values, the > > > > > value being the number of milliseconds since Jan. 1, 1970 GMT. > > > > > Keep in mind that the count of milliseconds does not conform to > > > > legal nor physical elapsed time for any observer. See here for > > > > morehttp://www.ucolick.org/~sla/leapsecs/epochtime.html -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
