From: Jon Seymour <jon.seymour@gm...>  20120122 10:06:36
Attachments:
Message as HTML

G'day all. I recently stumbled across JSR310 and thence UTCSLS which I read and thought, what a neat solution! Back to the description of Coordinated Universal Time in version 0.3.0 of the JSR, to wit: The standard "continuous" timescale intended for civil purposes, defined by international standard. It follows TAI except for the insertion or removal of an integral number of leap seconds which are intended to keep UTC closer to the real and variable length of a solar day. These leap seconds are a discontinuity in the timescale, meaning that it is not truly "continuous".  I was a little confused at first about the description of UTC as being discontinuous, since I thought one of the points of UTC was precisely to eliminate discontinuities. So 20081231 23:59::59 is followed by 23:59:60 which is, in one sense continuous. Thinking about it some more, though, I realized that I had ignored the word timescale in the definition. What is discontinuous is the function that converts a UTC timestamp into a scalar value, so: s = scalar(u, t) where u is the UTC value and t is the time at which the conversion is made. For a given value of t, scalar(u, t) is continuous for all suitably large values of u, but the problem really is that the reverse is not true  for a given value of u, scalar(u, t) is not continuous for all values of t, and that's because of leap second announcements which cannot be predicted in advance. Not suggesting anything necessarily needs to change in the wording of the specification, but I thought I would share this thought process with the list just on case it is of any use to others. jon. 
From: Stephen Colebourne <scolebourne@jo...>  20120123 15:04:59

Yes, UTC is an interesting beast that is not predicatable into the future. Thats why the UTC class proper stores days and nanoofday, which will stay accurate. Stephen On 22 January 2012 10:06, Jon Seymour <jon.seymour@...> wrote: > G'day all. I recently stumbled across JSR310 and thence UTCSLS which I > read and thought, what a neat solution! > > Back to the description of Coordinated Universal Time in version 0.3.0 of > the JSR, to wit: > > The standard "continuous" timescale intended for civil purposes, defined by > international standard. It follows TAI except for the insertion or removal > of an integral number of leap seconds which are intended to keep UTC closer > to the real and variable length of a solar day. These leap seconds are a > discontinuity in the timescale, meaning that it is not truly "continuous". > >  > > I was a little confused at first about the description of UTC as being > discontinuous, since I thought one of the points of UTC was precisely to > eliminate discontinuities. So 20081231 23:59::59 is followed by 23:59:60 > which is, in one sense continuous. > > Thinking about it some more, though, I realized that I had ignored the word > timescale in the definition. > > What is discontinuous is the function that converts a UTC timestamp into a > scalar value, so: > > s = scalar(u, t) > > where u is the UTC value and t is the time at which the conversion is made. > For a given value of t, scalar(u, t) is continuous for all suitably large > values of u, but the problem really is that the reverse is not true  for a > given value of u, scalar(u, t) is not continuous for all values of t, and > that's because of leap second announcements which cannot be predicted in > advance. > > Not suggesting anything necessarily needs to change in the wording of the > specification, but I thought I would share this thought process with the > list just on case it is of any use to others. > > jon. >  > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL  plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnowdev2 > _______________________________________________ > threetendevelop mailing list > threetendevelop@... > https://lists.sourceforge.net/lists/listinfo/threetendevelop > 