Thursday, December 30, 2010

[android-developers] Re: How to store date and time in database

Somehow I missed seeing your first paragraph when I responded before.

Your first paragraph seems to be *exactly backwards*. You appear to be
mixing calendars and times.

DST has no bearing on subtracting two times, any more than timezone
does.

In general, if you want to calculate tine intervals, subtracting
seconds is the ONLY sane way to do it. Days, and thus weeks, and
obviously months and years, are simply ill-defined. Seconds (and
multiples thereof) are the only time representation in common use with
a precise definition. (Minutes, hours, and even days only have a
precise definition if defined in terms of the second; it is ambiguous
whether you're referring to time or calendar intervals).

DST is a *local presentation* issue.

Perhaps what you're trying to get at is the special case of wanting to
add "7 days", or "two months" to a calendar, so that, e.g. 12:30 pm on
Tuesday becomes 12:30pm on the next Tuesday, regardless of leap
seconds or DST changes. In that case, you do want to strictly deal
with the calendar representation (ala Java's Calendar class).

But that's a calendar operation, not a time operation. One certainly
shouldn't confuse them, and one should not add 60*60*24*7 seconds to
do a calendar operation.

But if what you need to know is "how much time is between last Tuesday
at 12:37:38.023 and this Tuesday at 12:37:38.023", then subtraction of
a TIME representation is EXACTLY the right operation.

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

No comments:

Post a Comment