[9fans] gmtime() ulong

[9fans] gmtime() ulong

[cinap_lenrek]

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

Re: [9fans] gmtime() ulong

[cinap_lenrek]

arg, screwed up... that should'v been (long) not (vlong)... too
drunk, too late...

--
cinap

Re: [9fans] gmtime() ulong

[erik quanstrom]

> 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.

on the one hand one could just expect long to be always 64-bits
by 2038.  but that seems timid.

i'd rather see the time base switched to nanoseconds.  then the bother
of the switch  might benefit us while we still use the system.  :-)  2038
is still 25 years off.

a more pressing worry for me is the fact that haswell chipsets, and
newer atom motherboards only support xhci.

- erik

Re: [9fans] gmtime() ulong

[Richard Miller]

I can't mind-read the intention of the change, but the effect
is to do unsigned div/mod instead of signed.  This allows the
time value to be treated as an unsigned 32-bit number, so we
should be looking at a 2106 problem not a 2038 problem.

Unfortunately while gmtime() is right, asctime() is getting
its centuries in a twist:

term% date 4070930400
Thu Jan  1 06:00:00 GMT 2099
term% date 4102466400
Fri Jan  1 06:00:00 GMT 2000

Re: [9fans] gmtime() ulong

[erik quanstrom]

On Mon Jun  3 15:10:31 EDT 2013, 9fans@hamnavoe.com wrote:
> I can't mind-read the intention of the change, but the effect
> is to do unsigned div/mod instead of signed.  This allows the
> time value to be treated as an unsigned 32-bit number, so we
> should be looking at a 2106 problem not a 2038 problem.
>
> Unfortunately while gmtime() is right, asctime() is getting
> its centuries in a twist:
>
> term% date 4070930400
> Thu Jan  1 06:00:00 GMT 2099
> term% date 4102466400
> Fri Jan  1 06:00:00 GMT 2000

is that really going to work out?  plenty of code has
	if(fnthatreturnstime() < 0)
		error case ....

- erik

Re: [9fans] gmtime() ulong

[Richard Miller]

> is that really going to work out?

Somebody must have thought so:

     TIME(2)                                                   TIME(2)

     NAME
          time, nsec - time in seconds and nanoseconds since epoch
...
          Times from time should be stored in and treated as ulongs;
          this extends the range of valid times into the year 2106.