definition of epoch numbers and shortened versions of:

The underlying time unit in all time measurements here is 1/8 nsec. All time is
referred to in these units. The timestamp unit records 49 bits of this timing
information, resulting in a rollover period of 70368.74418... sec, or roughly
19 hours, 32 min, 48.74sec.

in the absolute time option for the timestamp recording programs, the
timestamp tag gets the seconds since midnight jan 1, 1970 added to the
recorded value, modulo 2^49 so the rollover is still a problem.

for partitioning the continuous stream of event data in manageable portions,
events are packaged in epochs, where an epoch is defined as a stretch of time
with the same bits starting on from bit32. Then, an event time can be referred
to by its epoch and the offset within the epoch, obeying the relation
  real time (in 1/8 nsec) = epoch<<32+offset

offset is then just the least significant 32 bit of the timing
information. Typically, this entry is handled as an unsigned integer. One
epoch covers exactly 0.536870912 seconds.

For referring to a particular epoch, the epoch is truncated to its lower 32
bits, and again handled as an unsigned integer. An epoch rollover will take
place with a period of 2^61 nsec, or approximately 73 years. Using the
absolute timing convention, the first rollover will happen on January 24,
23:56:49 GMT 2043. The first time it becomes relevant that epoch is an
unsigned int and not an int is on July 14, 23:58:24 GMT 2006. This time
corresponds to epoch 0x80000000.

In various stream files, there has to be a reconstruction of the full
epoch. This extension is one by using a local clock of the PC, and assumes
that the epoch extension is done shortly after the recording of the time
stamping.

To cover slight mismatches of the timing information generated by the
timestamp card and the computer time requested at the conversion moment, the
ambiguity resolution should allow for the timestamp time to be either slightly
in the future (up to 1/4 of the timestamp rollover or 4h53'12") or in the past
(3/4 of the timestamp rollover or 14h39'36") of the currently obtained
computer time. If aep is an epoch number calculated from local computer time,
and tep is the epoch from the timestamp card (limited to 17 bits), then the
final epoch is calculated via
  finalepoch = (aep & 0xfffe0000)+(tep & 0x0001ffff)+correction
where correction is 0, 0x00020000 or 0xfffe0000. The addition is carried out
modulo 32 bit, and the correction is determined by the overlapping two bits
from aep and tep. The correction can be noted in an array corr, with an
array index overlap, with 
     overlap = ((aep>>15)&3 )+ ((tep>>13) & 0xc).
To fulfill the requirement of the time difference in pos and neg direction, 
the array must read
  corr[]={0,0,0,+, 0,0,0,0, -,0,0,0, -,-,0,0}
where 0,+ and - represent the three possible entries for correction mentioned
above.

In a resulting timing file there should be no ambiguity for the absolute time
determination. In type-2 files, the tagged epoch is the only information
available. In digesting type-1 files, the upper 17 bits from epoch should come
from the 
tag, and the lower 15 bit from the timestamp unit, since the correction of a
mismatch has taken place already in the process of partitioning from the raw
data stream. 

last change 7.9.05chk