Knowing the policy is not an adequate solution, because the information about leap seconds just isn't there. You can add "external" knowledge of historical leap seconds, but you still can't tell the difference between a leap second, and one second prior to that leap second (or after, depending on your "policy").
And it's exactly time intervals that fail using unix time. This is what I hadn't realized; I thought Unix time actually counted seconds. But no, the POSIX committee thought it better to make the time conversion libraries slightly simpler, and have the Unix clock be discontinuous about once every year and a half. It actually jumps backwards! Which makes it useless as a general representation of time at 1 second precision. It's fine if you just want to know when your meeting is, but is a disaster if you want to know if one file was written before another. Of course, POSIX doesn't define file times with sub-second resolution, but Linux does. But there are tons of things that DO make use of timestamps, and monotonic times are absolutely essential in many applications. Your idea of making the second longer is good for computers, and I liked it at first glance -- but it would be lousy for everything else, as it would require redefinition of just about everything! The value of 'c', for example. BTW, there's no leap second this year. The last one was in 2008, so I'd guess there'll probably be one at the end of 2011. On Dec 29, 5:00 pm, DanH <danhi...@ieee.org> wrote: > 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 <r...@acm.org> 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 <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
