From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <9fd46f174ab35243e649a8cec6705de6@gmx.de>
Date: Mon,  3 Jun 2013 01:31:10 +0200
From: cinap_lenrek@gmx.de
To: 9fans@9fans.net
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] gmtime() ulong
Topicbox-Message-UUID: 606fd128-ead8-11e9-9d60-3106f5b1d025

a while ago, libc's gmtime() was changed like this:

-	hms = tim % 86400L;
-	day = tim / 86400L;
+	hms = (ulong)tim % 86400L;
+	day = (ulong)tim / 86400L;
	if(hms < 0) {
		...

i asked what this change tried to intend here:

http://9fans.net/archive/2013/05/12

anyone?

on the topic, i thought about how to handle the 2038 problem
in general with 9p which uses unsigned 32bit integers for atime
and mtime fields.

whenever we get 32 bit time field that cannot represent time,
we could interpret it in context of the system time.

say, if we get to interpret a mtime or atime filed from (old?)
9p server, we do:

/* new types */
vlong now, mtime;

/*
 * get current system time, with some form of new time()
 * function returning 64bit signed integer.
 */
now = time(0);

/*
 * olddir->mtime being 32bit unsigned integer from legacy system
 * and mtime being new 64bit signed integer time
 */
mtime = now + (vlong)(olddir->mtime - (now & 0xFFFFFFFF));

so whenever we get some old 32 bit long time type, we assume that the
values just wrap arround and we have to interpret it in context
to the current time assuming that the time delta to current time will
be smaller than 2^32 seconds.

does this make any sense?

--
cinap