[1033] in Coldmud discussion meeting

Re: [COLD] behaviour of localtime()

daemon@ATHENA.MIT.EDU (Tue Jul 23 12:57:55 1996 )

Date: Tue, 23 Jul 1996 11:19:52 -0500 (CDT)
From: Brad Roberts <braddr@puremagic.com>
To: Brandon Gillespie <brandon@tombstone.sunrem.com>
cc: coldstuff@cold.org
In-Reply-To: <Pine.BSF.3.91.960723091352.19109A-100000@tombstone.sunrem.com>


> 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) 
>     4. INTEGER hours (0-23)) 

I'd leave these time related ones alone..shifting these all up one 
changes the meaning of the value and would require subtracting to print 
out correctly, which is what you're trying to avoid having to do in the 
first place..  The others I agree with.

>     5. INTEGER day of month (1-31) 
>     6. INTEGER month in year (0-11) 
>     7. INTEGER year 
>     8. INTEGER week day (0-6) 
>     9. INTEGER year day (0-365) 
>    10. INTEGER is daylight savings in effect? 
>    11. STRING time zone name 
> 
> 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)
>     4. INTEGER hours (1-24)
>     5. INTEGER day of month (1-32)
>     6. INTEGER month in year (1-12)
>     7. INTEGER year
>     8. INTEGER week day (1-7, Sunday=1)
>     9. INTEGER year day (1-366)
>    10. INTEGER is daylight savings in effect?
>    11. STRING time zone name
> 
> 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?
> 
> -Brandon Gillespie
>