Re: Introduction of long term scheduling

2007-01-04 Thread Michael Deckers
   On 2007-01-03, Poul-Henning Kamp commented on Bulletin D 94:

  That's an interesting piece of data in our endless discussions about
  how important DUT1 really is...

   So it appears that DUT1, an approximation of UT1 - UTC, is not of much use,
   even though it is disseminated with many time signals. On the other hand,
   POSIX implementors need the values of DTAI = TAI - UTC, the count of leap
   seconds, at least for those UTC timestamps in the future as may occur
   during the operation of the system.

   This leads me to my question: would it be helpful for POSIX implementors
   if each and every UTC timestamp came with the corresponding value of DTAI
   attached (instead of DUT1)? Would this even obviate the need for a leap
   seconds table?

   I realise that this would require changes or extensions to the time
   interfaces of POSIX (eg, a time_t value alone could no longer encode a
   complete timestamp). My question is just whether such timestamps,
   indicating both UTC as time-of-day and TAI as interval time, could
   be a viable alternative to the frequent updates of leap second tables.

   Michael Deckers


Re: Mechanism to provide tai-utc.dat locally

2006-12-29 Thread Michael Deckers
   On 2006-12-09, Clive D.W. Feather challenged, and I couldn't resist:

  For something more challenging, try the 8 Bank Holidays in England:

  ...
  (8) Second weekday after 24th December.

   second weekday after 24th December in Gregorian year( Y )
  =  Gregorian calendar( Y, December, 26 )
 + 2·(floor( D / 5 )) d - (floor( D / 7 )) d
  where
  D = day of the week number of Gregorian calendar( Y, December, 25 )
  (as in ISO 8601 with values in {1..7} and 1 for Monday)
= 1 + ((floor(Y/100) mod 4)·5 + (Y mod 100)·3 - (Y mod 4)·2) mod 7

   Sorry for being off-topic.

   Michael Deckers


Re: Accommodating both camps

2006-01-25 Thread Michael Deckers
   Poul-Henning Kamp wrote on 2006-01-25:

  If we abandon leapseconds today to avoid getting computer problems,
  we still have several hundred years of time to decide how to
  deal with any long term effects.

   I do not think so. When civil time is no longer connected to solar
   time (which is more than abandoning leap seconds!), then this affects
   legal and cultural issues all over the world, and a difference of a
   minute or so may well be relevant. Such a difference can accrue
   in 60 or 80 years.

   I am not just thinking of lawyers trying to exploit the difference
   between legal time in Britain (which is GMT) and the time scale
   disseminated by the NPL. What I find much more disquieting is first,
   that some problems may become apparent only very late, when the difference
   between TI and UT is large enough, and, secondly, that it appears to
   be very difficult to say which areas of daily life will be affected.

   On the other hand, I believe that most if not all of these problems
   will not be life-threatening -- whereas many of the problems with
   leap seconds and computers may well be. So this, rather than other
   technical merit may finally decide the question. But again, giving up
   leap seconds in UTC is not the same as accepting atomic time as civil
   time.

   Michael Deckers


Re: The real problem with leap seconds

2006-01-18 Thread Michael Deckers
   On 2006-01-18, Steve Allen wrote:

  Now I am confused.

  By my reading of the documents, ITU-R did not define DTAI until the
  most recent revision of TF.460 in 2002.  DUT1 had been defined since
  very early on.

   You are right, the name DTAI has apparently been introduced in 2002. It
   also appears in [ITU-R TF536.2 2003] and [ITU-R TF686.2 2002]. It is
   defined in these documents as the values of TAI - UTC and is described
   as the contribution of the IERS to the determination of UTC. Such values
   of TAI - UTC are published back to 1972 (step function) and even to 1961
   (piecewise linear function).

   Since I wanted to describe how I understood Mark Calabretta's
   description of UTC as essentially the same as TAI except for the
   variable radix notation for the (whole) second field in the time
   of day values, I took DTAI as a convenient abbreviation of
TAI - ( UTC value when interpreted with
a fixed radix for the second field )
   I avoided writing UTC for TAI - DTAI because this would contradict
   the assumption that UTC is just TAI plus additional information.
   Hope that clarifies things a bit.

   Michael Deckers


Re: The real problem with leap seconds

2006-01-16 Thread Michael Deckers
   Mark Calabretta wrote:

  You're still not getting the point that UTC is just a representation
  of TAI.

   OK, let me try again.

   UTC (since 1972) is a disseminated timescale that is equal to TAI
   except for additional date and time codes transmitted with the
   signal. These codes indicate the values of TAI - DTAI for each
   full minute of TAI - DTAI.

   In a reading of UTC, (the most recent values of) these date and
   time codes can be taken as is so as to yield a reading that
   approximates UT1. The codes may also be used to derive the value of
   DTAI (from a table of leap seconds since 1972), and thus, to yield
   a reading of TAI. When a timestamp is characterised as UTC
   (rather than TAI), then the first type of reading is implied.

   In order to ensure a unique derivation of TAI from a recorded
   reading of UTC in the vicinity of a positive leap second (where
   DTAI jumps up by 1 s and the value of TAI for a given value of
   TAI - DTAI is not unique), the UTC reading that corresponds to the
   earlier TAI value shall be recorded with a second field = 60 s,
   and the other UTC reading, with a second field  60 s.

   Michael Deckers (still trying to understand the topology you referred to)


Re: The real problem with leap seconds

2006-01-13 Thread Michael Deckers
   On 2006-01-13, Mark Calabretta wrote:

  I have two time scales, TAI and UT1, that tick at very slightly
  different rates.  I want to make TAI the basis for civil time keeping
  but I need to make adjustments occasionally to keep it in step with
  UT1.  How do I do it?

  The answer provided by CCIR was to represent TAI in a variable-radix
  notation that matches (or appears to match), to within 0.9s, that of
  UT1 expressed in the usual calendar/clock format.  This is done by
  varying the radix of the seconds field in a pseudo-sexagesimal clock
  format from 60 to 61 (or in principle 59) on occasions announced 6
  months in advance.

  So if asked for a definition I would say that UTC (post 1972) is a
  representation of TAI such that ... (you know the rest).

  The point is that UTC is simply a representation of TAI.  Writing UTC
  as a real reveals it to be TAI.

   I believe I'm now grasping what you mean: the rate of UTC is the same
   as the rate of TAI (since 1972), that is, the derivative
   d( UTC )/d( TAI ) = 1. Hence, when I integrate the ticks of UTC
   I must get TAI, up to an integration constant. This is correct.
   The integral of d( UTC ) is TAI (up to an integration constant),
   but this integral is UTC only where UTC is a continuous function
   of TAI.

   Astronomers who write UTC as a real (eg, in JD or MJD notation)
   want an approximation of UT1 to point their telescopes, they do
   _not_ want TAI. They use UTC as a timescale whose values are
   close to UT1, but whose rate nevertheless is d( UTC ) = d( TAI )
   and not d( UT1 ). Such a function cannot be continuous (and it
   cannot be differentiable everywhere). At the latest discontinuity
   of UTC, it jumped from a little bit after UT1 to a little bit before
   UT1.

   Michael Deckers


Re: The real problem with leap seconds

2006-01-13 Thread Michael Deckers
   On 2006-01-13, Ed Davies wrote:

  This conversation is making something of a meal of a simple
  point.  You can treat UTC as a real in either of two ways:

  If you don't count the leap seconds then the good news is that
  days are all 86 400 seconds long but the bad news is that the
  real is undefined during the leap second and there's a
  discontinuity (or rather, a surprising continuity in that
  at some point it's 23:59:59.99 and a whole second and
  a tiny bit later it's 00:00:00.).

  If you do count the leap seconds then that real is the same
  as TAI but the days it's divided up into aren't all 86 400
  seconds long.

  Sort of like, is it a particle or a wave? :-)

   At the risk of being misunderstood as sarcastic: if
   users of UTC were really expected to understand such
   strange concepts (Schrodinger time) I would plead for the
   immediate abolishment of UTC. Why cannot UTC be simply taken as
   the reading of a clock that runs at the same rate as TAI and
   that is is set back by a second every once in a while?

  The truth is that UTC only really makes sense as a year,
  month, day, hour, minute and second value.  Years have 12
  months, months have 28, 29, 30 or 31 days, days have 24
  hours, hours have 60 minutes, minutes have 59, 60 or 61
  seconds.

   Then why can the IERS express UTC in the MJD notation?

  The use of the 23:59:60 notation is described in ISO 8601.
  Is it also specified in TF.460?  If so, how do they relate
  it to the notion of DTAI?

   Yes, it is specified in [ITU-R TF.460-6. Annex 3]:

   The dating of events in the vicinity of a leap-second shall be
   effected in the manner indicated in the following Figures:

   Follow some pictures; for a positive leap second, it looks like:

  event
  |leap second
+-|---+
| |   |
 |  | |   |   |
 |  | |   |   |
59 60 0   1
  |
---30 June, 23h 59m--|--1 July, 0h 0m


Designation of the date of the event
|
|
|
V
   30 June, 23h 59m 60.6s UTC

   They also say:

  C Coordinated universal time (UTC)

  UTC is the time-scale maintained by the BIPM, with assistance from
  the IERS, which forms the basis of a coordinated dissemination of
  standard frequencies and time signals. It corresponds exactly in
  rate with TAI but differs from it by an integer number of seconds.
  The UTC scale is adjusted by the insertion or deletion of seconds
  (positive or negative leapseconds) to ensure approximate agreement
  with UT1.


  E DTAI

  The value of the difference TAI � UTC, as disseminated with time
  signals, shall be denoted DTAI. DTAI = TAI - UTC may be regarded
  as a correction to be added to UTC to obtain TAI. The TAI - UTC
  values are published in the BIPM Circular T. The IERS should
  announce the value of DTAI in integer multiples of one second in
  the same announcement as the introduction of a leap-second (see �
  D.2).

   HTH

   Michael Deckers


Re: The real problem with leap seconds

2006-01-13 Thread Michael Deckers
   On 2006-01-13, Ed Davies wrote:

  Michael Deckers wrote:

. Why cannot UTC be simply taken as
the reading of a clock that runs at the same rate as TAI and
that is is set back by a second every once in a while?

  UTC can be taken the way you suggest most of the time (and
  that's clearly the way TF.460 wants to think of it), but it
  is then not well defined during the leap second itself.  To
  deal with that properly you have to either:

  1) think of a count of UTC milliseconds or whatever (including
  those in the leap second) which is then the same as TAI or

  2) work in separate fields with a 61 second minute.

   Right, UTC timestamps are ambiguous (in the sense that the
   corresponding TAI value is not known) in the vicinity of
   positive leap seconds, and the notation with a second
   field = 60 s is one (elegant) way to disambiguate.

   Another way to disambiguate is to record the value of DTAI
   together with a UTC (or TAI) timestamp. Such a method is
   standardised in ISO 8601 for denoting offsets from UTC,
   but only with minute resolution. I seem to remember that
   Clive Feather once proposed this for an extension to the
   C programming language.

   If you only need an approximation to UT1, however, there
   is no need to disambiguate, nor is it relevant which value
   of DTAI is applied during the leap second.

   Thanks for your patience.

   Michael


Re: Monsters from the id

2006-01-12 Thread Michael Deckers
   John Cowan wrote:

   [If TAI - 33 s were taken as the new basis for civil timescales, then]

  It is UTC that would be eliminated as the basis for local time.  It could
  be maintained for such other purposes as anyone might have.

   Yes, the IERS could maintain it as the timescale for a timezone
   whose local time approximates UT1 up to a second.

   Michael Deckers


Re: The real problem with leap seconds

2006-01-11 Thread Michael Deckers
   On 2006-01-10, Mark Calabretta wrote:

  I can't let this one pass - UTC is continuous and monotonic.  In fact,
  ignoring differences in origin, UTC = TAI.  Surprised?  If so then
  you're confusing a quantity with its representation (though in good
  company in doing so).

   I do not understand. As a function of TAI, UTC is neither continuous
   nor monotone increasing in the mathematical sense.

   In the defining document, [ITU-R TF.460-6], UTC is given as
UTC = TAI - DTAI
   where DTAI is a step function of TAI assuming as values only integral
   multiples of 1 s. Unless constant, such a function is not continuous
   on a connected domain in the mathematical sense. Hence, UTC is not
   a continuous function of TAI.

   At some instant when TAI took a value in the positive leap second between
   2006-01-01 + 00 h + 00 min + 32 s and 2006-01-01 + 00 h + 00 min + 33 s
   (the exact instant is not clear from [ITU-R TF.460-6 2002]), DTAI jumped
   from 32 s to 33 s; thus, UTC is not a monotone increasing function of
   TAI either.

   Perhaps you consider UTC as a function of something other than TAI where
   it may well be continuous or monotone (eg, as a function of itself, UTC
   trivially is both continuous and monotone).

   Reference:
[ITU-R TF.460-6] Recommendation ITU-R TF.460-6
 Standard-frequency and time-signal
 emissions. 2002 Geneva.

   Michael Deckers


Re: The real problem with leap seconds

2006-01-11 Thread Michael Deckers
   On 2006-01-11, David Malone wrote:

  [A lot of discussion on this list seem to revolve around people
  understanding terms in different ways. In an impractical example
  of that spirit...]

   Anyway: excuse me for repeating some basics of classical mechanics;
   but I believe it to be necessary.

  To say if TAI is a monotone function of UTC, you need to put an
  order on the set of possible TAI and UTC values. To say if UTC is
  a continuous function of TAI, you need to put a topology on both.

   Yes: there is an order on the set of values of timescales -
   it is a basic property of spacetime models that one can distinguish
   past and present, at least locally. Spacetime is a differentiable
   4-dimensional manifold, its coordinate functions are usually two
   times differentiable or more. In particular, the set of values of
   timescales does indeed have a topology (which is Hausdorff).

  To me, TAI seems to be a union of copies of [0,1) labelled by
  YEAR-MM-DD HH:MM:SS where you glue the ends together in the obvious
  way and SS runs from 00-59. You then put the obvious order on it
  that makes it look like the real numbers.

   TAI is determined as a weighted mean of the (scaled) proper times
   measured by an ensemble of clocks close to the geoid - so the
   values of TAI must belong to the same space as these proper times,
   which (being line integrals of a 1-form) take their values in the
   same space as the time coordinates of spacetime (such as TCB and TCG).
   No gluing is needed. And yes: this space is diffeomorphic to the
   real line.

   All of this is completely independent from the choice of a particular
   calendar or of the time units to be used for expressing timescale values.

  OTOH, UTC seems to be a union of copies of [0,1) labelled by
  YEAR-MM-DD HH:MM:SS where SS runs from 00-60. You glue both the end
  of second 59 and 60 to the start of the next minute, in adition to
  the obvious glueing.

  I haven't checked all the details, but seems to me that you can put
  a reasonable topology and order on the set of UTC values that
  will make UTC a continious monotone function of TAI. The topology
  is unlikely to be Hausdorf, but you can't have everything.

   If you subtract a time from a timescale value, you get another
   timescale value. If you mean to say that UTC takes its values in a
   different space than TAI then you cannot agree with UTC = TAI - DTAI,
   as in the official definition of UTC. And if you say that
   UTC - TAI can be discontinuous (as a function of whatever)
   with both UTC and TAI continuous then you must have a subtraction that
   is not continuous. Strange indeed. Where did I misinterpret your post?
   And can you give some reference for your assertions?

   Michael