From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon,  3 Jun 2013 15:11:59 -0400
To: 9fans@9fans.net
Message-ID: <1a3f7ddc348d943dd2b9e49f49173f80@ladd.quanstro.net>
In-Reply-To: <07ceecfd621281a30ced4eb9226e0c24@hamnavoe.com>
References: <07ceecfd621281a30ced4eb9226e0c24@hamnavoe.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] gmtime() ulong
Topicbox-Message-UUID: 62a6aad4-ead8-11e9-9d60-3106f5b1d025

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