[1034] in Coldmud discussion meeting

Re: [COLD] behaviour of localtime()

daemon@ATHENA.MIT.EDU (Tue Jul 23 14:06:12 1996 )

From: Andrew Wilson <andrew@aaaaaaaa.demon.co.uk>
To: Brandon Gillespie <brandon@tombstone.sunrem.com>
Date: Tue, 23 Jul 1996 17:14:07 +0100 (BST)
Cc: coldstuff@cold.org
In-Reply-To: <Pine.BSF.3.91.960723091352.19109A-100000@tombstone.sunrem.com> from "Brandon Gillespie" at Jul 23, 96 09:18:43 am

> Right now localtime works like:
> 
>     1. INTEGER time (same as returned by the function time()) 
>     2. INTEGER seconds (0-59) 
>     3. INTEGER minutes (0-59) 

[snippety...]

> Which is basically a raw dump of the C function localtime().  Because 
> Cold scales arrays starting at one rather than zero, I think I will change 
> it to add one to elements 2 - 9 (excluding the year and day of the month), 
> instead giving you:
> 
>     1. INTEGER time (same as returned by the function time())
>     2. INTEGER seconds (1-60)
>     3. INTEGER minutes (1-60)

[snip...]

> The reason for this is any likely use of localtime() in ColdC will 
> inevitably require you to add one to the value, so why not do it in 
> native code rather than interpreted code?

What is this, April 1st?  Under this proposal I'll be forced to
subtract one from seconds and minutes to get the right answer?  I
think, on general principal, that you shouldn't dick with something
so important as localtime(), you'll be up to your ass in FAQ 'er
why is cold's time code not standard C, why is it always off by
one, is my system misconfigured?!?!' and other perfectly sensible
bemusement.

> -Brandon Gillespie

Ay.