[LEAPSECS] honest-to-god copper

[M. Warner Losh]

In message: <369B7A95-4CA7-4E5F-81AD-4445D810914C at noao.edu>
            Rob Seaman <seaman at noao.edu> writes:

: Stating that not taking into account leap seconds is useful because

: "most applications do not take into account the existence of leap

: seconds" is a rather circular justification.


Well, it is a deatil of time keeping that many applications do indeed
get wrong, due mostly to ignorance.


: Many applications (don't know about "most") have civil timekeeping

: requirements.  Civil timekeeping is layered on UTC, which requires

: leap seconds.  Thus many (or most) applications require leap seconds,

: whether the programmers and project management want to admit it or

: not.


Most applications that have a civil timekeeping requirement tend to
have a large tolerance for errors.  "Good enough" time keeping that
gets some details wrong, but produces more intuitive results is often
sufficient to meet the applications' requirements.  Who cares if a log
message is off by a second during or near a leap second.  Most
applications could care less if there's a larger than normal, but
still reasonable error in these cases.  They are also tolerant of
errors around these events too.  Again, a case of "good enough"
instead of "perfect".


: Most applications require arithmetic.  One could define an "Addition"

: class in which 1+1 is 3.  And a "TrueAddition" class in which 1+1 is 2

: for "applications needing to take into account the way arithmetic

: actually works".  Reifying an object to a nonsensical class is not

: made a logically coherent action just because you've checked your code

: into a source repository and written documentation with disclaimers.


I think the real analogy here would be "Addition" would be 1 + 1 is "A
couple" or "a few" since the application only cares for the three
cases 0, 1, more than one anyway.  "TrueAddition" would give the
pedantically correct answer, maybe at the cost of performance or
complexity to the code for when the application cares to a high level
of resolution.

Don't get me wrong, I tend to be in the 'all applications should
always be pedantically correct' camp, especially when it comes to time
keeping.  But in reality, the 'bad' consequences of a skipped leap
second, a clock error of 1-2s, etc just are so small (or nonexistent)
than I totally understand the motivation for these classes, even if I
think they are silly...

Warner



: Rob

: --

: 

: On Jun 7, 2010, at 10:34 AM, Steve Allen wrote:

: 

: > In the Manhattan project plutonium was copper, and copper was

: > honest-to-god copper.

: >

: > In the Java JSR-310 "Date and Time API"

: > https://jsr-310.dev.java.net/userguide.html

: > we see this:

: >

: > 	Time scales

: >

: > 	The Instant class operates on a time-line model that doesn't

: > 	exist in reality.  Specifically it assumes that leap-seconds

: > 	do not exist, and that there are always 60 seconds in a

: > 	minute.

: >

: > 	These simplifications are useful because most applications do

: > 	not take into account the existence of leap seconds.  If your

: > 	application needs to takeinto account leap seconds then an

: > 	alternate class is needed.  The TimeScaleInstant class

: > 	represents an instant in time measured againsta specific

: > 	TimeScale.  The supplied scales include TAI and True-UTC.

: >

: > "True-UTC", as opposed to just plain "UTC".  Just plain "UTC" is not

: > the entity defined by ITU-R TF.460, but a (dare I use the word)

: > proliferated time scale, something new created by them.

: >

: > How long will it be before it is necessary to make the distinction

: > between "TAI" in JSR-310 and "True-TAI" as defined by BIPM?

: >

: > I think I would call this not "proliferation" but "dilution of

: > trademark".

: >

: > Who is in charge of these time scales?

: > The defining agencies and their documents, or various different sets

: > of time scale users and their documents?

: >

: > --

: > Steve Allen <sla at ucolick.org> WGS-84 (GPS)

: > UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855

: > University of California Voice: +1 831 459 3046 Lng -122.06015

: > Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

: > _______________________________________________

: > LEAPSECS mailing list

: > LEAPSECS at leapsecond.com

: > http://six.pairlist.net/mailman/listinfo/leapsecs

: 

: _______________________________________________

: LEAPSECS mailing list

: LEAPSECS at leapsecond.com

: http://six.pairlist.net/mailman/listinfo/leapsecs

: 

: