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 <danhi...@ieee.org> 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 <r...@acm.org> 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 <sla29...@gmail.com> wrote: > > > > On Dec 26, 11:39 pm, Kostya Vasilyev <kmans...@gmail.com> 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
