Subject: filexfer time stamps

From: [email-masked] (Niels M�ller)
Date: 11 Jan 2001 14:56:38 +0100

In the filexfer protocol, time stamps (in file attributes) are
represented as uint32. The consequences are

1. We get a year 2106-something problem. This doesn't matter much, as
   the protocol version can be increased and the timestamp field
   expanded in good time before that.

2. The protocol can't deal at all with files older than 1970. Perhaps
   the spec should note that the special value 0 means any time before
   1970? Or should we use a _signed_ number instead (giving us a "2038
   problem")? For the next 30 years, files older than 1970 will be
   more common than files dated after 2038. Not that I have any such
   old files (I was born 1971 ;-), but I would expect for instance any
   ITS mirror to have some.

/Niels

---

From: Sami Lehtinen <[email-masked]>
Date: Fri, 12 Jan 2001 01:06:33 +0200

Niels Möller, on January 11. 2001, wrote:
  : In the filexfer protocol, time stamps (in file attributes) are
  : represented as uint32. The consequences are
  : 
  : 1. We get a year 2106-something problem. This doesn't matter much, as
  :    the protocol version can be increased and the timestamp field
  :    expanded in good time before that.
  : 
  : 2. The protocol can't deal at all with files older than 1970. Perhaps
  :    the spec should note that the special value 0 means any time before
  :    1970? Or should we use a _signed_ number instead (giving us a "2038
  :    problem")? For the next 30 years, files older than 1970 will be
  :    more common than files dated after 2038. Not that I have any such
  :    old files (I was born 1971 ;-), but I would expect for instance any
  :    ITS mirror to have some.

Should this use a 64 bit signed integer? This would put the date range
to something like -292471206707 to 292471210647 (in years). Of
course, modern operating systems don't handle that (yet), but are we
so far from that? 2038 is approaching us like a train...

Of course, this could be a "little" overkill. 292 billion years to the
past or the future could be considered excessive.

OTOH, time_t usually is a 32 bit signed integer. This would leave us
37 years to handle the problem, but we couldn't have files dated
before the universe existed... :)

Cheers,
-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]