Re: [threeten-develop] UTC-SLS

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Conceptually, I have no problem with smoothing the leap over the whole
day. However, it is (a) not specified anywhere (not that UTC-SLS is
perfect, but it is written as a spec), and (b) it reduces the issue to
a small period of less than 20 minutes, which feels preferable to me
until standards committees completely redefine the second.

As I've said before, the vast majority of business analysts in the
industry will struggle to answer questions on how the system should
behave around time-zone changes, let alone leap-seconds.

Stephen

On 29 January 2011 19:23, Doug Lindholm <dou...@gm...> wrote:
> Legacy APIs that I have used will allow a day with a leap second to simply
> have 86401 seconds. We often use times in units of days (e.g. Julian Date)
> where fractional days use 86401 on days with a leap second. So, instead of
> spreading the leap second over 1000 seconds, this approach effectively
> spreads it over the entire day. I'd suggest that the latter would be much
> more palatable among users than the former.
>
> We recently ran into a problem where a "one day ago" computation the day
> after a leap second naively used 86400 seconds and introduced an
> inconsistency. (Of course, the right thing to do would be to stay in TAI,
> but we had to interface with another API that expected Julian Date.) The
> assumption that one day is exactly 86400 seconds runs deep. Likewise, the
> notion that the duration of a second can vary is not on the forefront of the
> user's mind. Any time scale that allows otherwise is at risk of misuse. If
> you insist on relaxing the length of a second, spreading it over a day seems
> to have more precedence and reduces the "error".
>
> The only thing discontinuous about my UTC scale is that it doesn't reflect
> reality. That only matters if you use UTC time labels for measurements
> (physical or financial or...) that have temporal resolution on the order of
> one second or better. If you do, then your choice of UTC was a poor one and
> you deserve to have your derivatives blow up. Otherwise, my "discontinuous"
> UTC time scale is self-consistent and doesn't suffer from variable length
> seconds. If you bother to use the Duration capability, you can get away with
> it (assuming that a measurement didn't happen during the leap second, which
> you couldn't represent in UTC anyway). What use cases do you have in mind
> that would be more problematic with this discontinuity?
>
> Although the leap second definition allows for a negative leap second, I'm
> placing my bets that the current orbital mechanic trends will continue to
> slow the Earth's rotation.  (Though all bets may be off come 2012 and the
> end of the world. ;-)
>
> Doug
>
> On Fri, Jan 28, 2011 at 5:56 PM, Stephen Colebourne <sco...@jo...>
> wrote:
>>
>> On 29 January 2011 00:42, Doug Lindholm <dou...@gm...> wrote:
>> > Before I subject myself to the scorn of the leapsecond community, I'd
>> > like to run this idea by you.
>> >
>> > I have developed a simple Java API that can be used for scientific
>> > accuracy and for the average person who wants to ignore leap seconds. My
>> > "requirements" include:
>> >
>> > - One second is exactly 1 SI second.
>> > - One day is exactly 86400 SI seconds. (Though not an SI unit, the day
>> > is "accepted for use with" the SI units:
>> > http://www.bipm.org/en/si/si_brochure/chapter4/table6.html)
>> > - Leap seconds must be handled consistently.
>> >
>> > This disqualifies most leap-second aware APIs that I have seen,
>> > including this one.
>> >
>> > The way I see it, there is the "real" time scale and three times scales
>> > (inspired by JSR-310) that I use to model it for different purposes:
>> >
>> > - TAI: is as good as it gets
>> > - UTC: which we are forced to suffer when dealing with human time
>> > labels, when leap seconds matter
>> > - Native (for lack of a better term) that blissfully ignores leap
>> > seconds, as most APIs (including Java's) currently do.
>> >
>> > Instead of modifying the length of a second (e.g. UTC-SLS and pre-1972)
>> > or allowing a day to have an extra second, both of which can introduce
>> > dangerous inconsistencies, my UTC time scale has a discontinuity (wrt
>> > real time) at a leap second. It's very bad to do science with, but it is
>> > self-consistent. If you are watching a UTC clock from the perspective of
>> > real (or TAI) time, the UTC clock effectively pauses for one second. The
>> > duration of time that exists during a leap second simply does not exist
>> > in the UTC scale. The Native scale behaves the same way. The difference
>> > is that any conversion between a UTC and TAI scale or a Duration
>> > computed within the UTC scale will account for leap seconds. Any
>> > conversion involving a Native scale will ignore leap seconds. Thus, a
>> > Native time scale behaves as a Java user would expect. The TAI time
>> > scale is there to do it right. UTC enables the proper conversion between
>> > "civil" and "real" time.
>> >
>> > To complete the picture, an instant or Time is defined as a number
>> > (double) on a TimeScale. A TimeScale is defined by an epoch
>> > (java.util.Date), i.e. time zero, the duration of a time step (i.e.
>> > units), and the TimeScaleType (TAI, UTC, or Native). I don't attempt to
>> > deal with other irregular time constructs (e.g. month). For my
>> > scientific use case, if I have a time label, I use SimpleDateFormat to
>> > parse it into milliseconds to construct a UTC Time then convert it to
>> > TAI.
>> >
>> > Is there any precedent for this approach? Do you foresee any problems?
>> > Could JSR-310 adopt a similar approach?
>>
>> The problem with discontinuities is that they are more disruptive than
>> helpful. Plus, pausing doesn't work for negative leap seconds.
>>
>> All these different approaches are fairly well-known. TAI is simple
>> and well-defined. UTC is also well-defined, just often ignored. 86400
>> is most commonly used, but without defining how it is connected to UTC
>> or TAI. JSR-310 chooses to ue UTC-SLS because (a) its simple (b) it
>> works and (c) it keeps time continuously flowing forward. I like all
>> three of those properties.
>>
>> Stephen
>>
>>
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better
>> price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> threeten-develop mailing list
>> thr...@li...
>> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> threeten-develop mailing list
> thr...@li...
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>
>