I propose:
Second, in some operating systems, the value can be used with little or no
conversion. Conversion, when it is needed, requires only straightforward
computation. If the endian ordering is different than the ASN.1
representation of an INTEGER, then straightforward manipulation is needed
to obtain an equivalent integer value. If the epoch is different than the
one chosen for BinaryTime, addition or subtraction is needed to
compensate. If the granularity is something other than seconds, then
multiplication or division is needed to compensate. Also, padding may be
needed convert the variable length ASN.1 encoding of INTEGER to a fixed
length value used in the operating system.
Russ
At 07:20 AM 9/17/2004, Peter Sylvester wrote:
>
> > > >1.1 BinaryTime
> > > >
> > > > Many operating systems represent date and time as an
integer. This
> > > > document specifies an ASN.1 type for representing a date and
time in
> > > > a manner that is compatible with these operating systems. This
> > > > approach has several advantages over the UTCTime and
GeneralizedTime
> > > > types.
> > > >
> > > >Not many systems represent data and time in BER as far as I remember.
> > >
> > > I do not understand this comment. The quoted text says that operating
> > > systems use an integer, not a character string. BER (or other
> > encoding) is
> > > going to be applied in either case. This is essential to resolve
endian
> > > issues at a minimum.
> >
> >An integer encoded in BER is AFAIK not the way to encode seconds on
> >on any known system. (I have even forgotten x-endian stuff.).
>
> I am very confused here. Many operating systems use an int32 or an int64
> for time values. These are easy to DER encode as an ASN.1 INTEGER.
>
There is a difference between 'easy to do' and 'nothing to do'.
As P.G. pointed out (forgetting at least one other machine type) even if
time values are represented as integers, the granularity is not the same
everywhere.