Rob Seaman said:
> Which raises the question of how concisely one can express a leap
> second table.

Firstly, I agree with Steve when he asks "why bother?". You're solving the
wrong problem.

However, having said that:

> So, let's see - assume:
>        1) all 20th century leap seconds can be statically linked
>        2) start counting months at 2000-01-31
> We're seeing about 7 leapseconds per decade on average, round up to
> 10 to allow for a few decades worth of quadratic acceleration (less
> important for the next couple of centuries than geophysical noise).
> So 100 short integers should suffice for the next century and a
> kilobyte likely for the next 500 years.  Add one short for the
> expiration date, and a zero short word for an end of record stopper
> and distribute it as a variable length record - quite terse for the
> next few decades.  The current table would be six bytes (suggest
> network byte order):
>        0042 003C 0000

That's far too verbose a format.

Firstly, once you've seen the value 003C, you know all subsequent values
will be greater. So why not delta encode them (i.e. each entry is the
number of months since the previous leap second)? If you assume that leap
seconds will be no more than 255 months apart, then you only need one byte
per leap second. But you don't even need that assumption: a value of 255
can mean 255 months without a leap second (I'm assuming we're reserving 0
for end-of-list).

But we can do better. At present leap seconds come at 6 month boundaries.
So let's encode using 4 bit codons:

* Start with the "unit size" being 6 months.
* A codon of 1 to 15 means the next leap second is N units after the
  previous one.
* A codon of 0 is followed by a second codon:
  - 1, 3, 6, or 12 sets the unit size;
  - 0 means the next item is the expiry date, after which the list ends
      (this assumes the expiry is after the last leap second; I wasn't
      clear if you expect that always to be the case);
  - 15 means 15 units without a leap second;
  - other values are reserved for future expansion.

So the present table is A001. Two bytes instead of six.

If we used 1980 as the base instead of 2000, the table would be:

    3224 5423 2233 3E00 1x

where the last byte can have any value for the last 4 bits.

I'm sure that some real thought could compress the data even more; based on
leap second history, 3 byte codons would probably be better than 4.

Clive D.W. Feather  | Work:  <[EMAIL PROTECTED]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[EMAIL PROTECTED]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: | Mobile: +44 7973 377646
THUS plc            |                            |

Reply via email to