Peter:
>The document states the rationale. No conversion to operating system
>representation and it is smaller. In what way do you find it limiting?
It doesn't go beyond 2038, whereas UTCTime at least goes to 2050.
Not so. A 4-octet value takes us to 2038. After that a 5-octet value is
needed. Many operating systems already use a 64-bit value internally.
The proposal isn't so much limiting as... bizarre. The ASN.1 time formats
have been around forever. everything supports them, and this proposal is for a
format that isn't even as "flexible" as the not-very-flexible UTCTime. What
real problem is this addressing? Why a time_t? Why not a 64-bit time to keep
the Java guys happy? Or the Windows nanoseconds-since-1600 time? Or the
Macintosh seconds-since 1904? You could make it a choice, so no-one would
feel left out, with at least one of the choices being an identified-by-OID
value so everyone could add their own favourite oddball format...
Any of these is possible, but a choice defeats the whole point, which is to
avoid complex conversion.
Russ