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
