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.



Reply via email to