On Mon, 5 Oct 2015 05:43, mdb(_at_)juniper(_dot_)net said:
This reminds me. I suspect we want to move to be explicit that the
timestamp is unsigned during RFC 4880bis, or we want to allocate
more bits and make it a 64-bit integer (8 octets).
I was thinking about this but:
3.1. Scalar Numbers
Scalar numbers are unsigned and are always stored in big-endian
format. Using n[k] to refer to the kth octet being interpreted, the
value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a
four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) +
n[3]).
Thus it is an implementation problem for 32 bit systems which still have
not switched from to a 64 bit time_t or fixed their implementation to
work with dates after 2038 (which is not a problem because only
(time_t)(-1) has a special meaning).
I doubt that we need to care about the year 2106 already in a v5 format.
The currnet POSIX-compliant epoch time_t starting at midnight January 1,
1970 using a signed 32-bit integer (4 octets) runs into trouble at 0x80000000
POSIX 2001 says in Base Definitions, line 13001:
- time_t and clock_t shall be integer or real-floating types.
it is not specified whether signed or unsigned and thus both are
allowed.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp