On Tue, 5 Jul 2005, Gaal Yahas wrote:

Regarding Time::Local fields, it's an object now, so the order of things

Should that be Time::localtime? In P5 there are Time::localtime & Time::gmtime, which are thin OO facades over the language builtins. Then there's the module Time::Local, which is entirely different.

All of those provide useful functionality, and probably Time::Local should be part of the language, _or_ localtime & gmtime should be in a library.

* .year is the Gregorian year, no 1900 offeset or anything like that.

Yes!

* .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.

And yes again!

* .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
  :-)

The more granularity the better, really. DateTime right now supports nanoseconds, which was a semi-arbitrary choice that seemed granular enough. Picoseconds is even better. Anyone who needs more probably has some sort of special hardware providing their data anyway, and will need a special interface to it (hand waving).

* 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.

I'd agree that this makes the most sense.


-dave

/*===================================================
VegGuide.Org                        www.BookIRead.com
Your guide to all that's veg.       My book blog
===================================================*/

Reply via email to