I've added localtime to pugs (r5233, 5236), to address Dave Rolsky's needs
for DateTime; but I'm noticing S29 doesn't spec this and nearby builtins
yet. I'd like to raise the questions I encountered / stipulations I've
made. Please let me know if I'm in error or update S29 if I am not.
Regarding Time::Local fields, it's an object now, so the order of things
matters less now than it did in p5. The fields I've made available
naturally follow GHC's CalendarTime type[1]. The important deviations
from p5 are:
* .year is the Gregorian year, no 1900 offeset or anything like that.
(Haskell doesn't promise accuracy in the readable version of
pre-Gregorian dates, which I think is okay for us as well, as long
as the opaque internal representation remains consistent. That's part
of where libraries such as DateTime can help.)
* .month and .wday are one-based. Sunday == 1. Haskell has them as
enums which avoids off-by one confusion completely; I made them like
I did because that's like humans think of them.
* .picoseconds - we don't promise this granularity is available by the
system, but I don't suppose we'll ever need anything finer than that
:-)
* Once we sort out context and want in pugs, I can return a List when
one is expected, instead of an object. Then the order of fields
becomes important and I'm inclined to go with year first, like the
Haskell module, so that least significant things come last. This is the
reverse of p5 Time::Local. When timelocal and timegm are implemented,
they will of course use whatever order their inverses use.
As for the function signatures:
multi sub localtime(Rat $?when = time) returns Time::Local { ... }
multi sub localtime(Int $sec, Int ?$pico = 0) returns Time::Local {...}
The first form uses the second, but might be less precise.
[1]
http://haskell.org/ghc/docs/latest/html/libraries/base/System.Time.html#t%3ACalendarTime
--
Gaal Yahas <[EMAIL PROTECTED]>
http://gaal.livejournal.com/
