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 ===================================================*/