On 2009-Feb-19, at 11:26 am, Dave Rolsky wrote:
What I want to see in Perl 6 is a set of very minimal roles that can be used to provide a simply object from gmtime() and localtime(). These objects should not handle locales, proper Olson timezones, string parsing, user-defined formatting, or math.
Yes; I myself haven't had to worry about leap-seconds before, and may very well never have to. Really basic math is common enough that it seems reasonable to include, though. And we get that by being able to numify times, though I'm not sure about officially making time() return a Num -- isn't that exposing an implementation detail? If I need an epoch value, I'd expect to have to say $time.epoch or $time.epoch(1970) or something.
our Time::localtime(:$time,:tz<GMT>)
Why can't we just have time() that takes a :tz adverb and dispense with gmtime() and localtime()? I also think that timezones should be required, so that it's impossible to have a time and not know what TZ it's supposed to be.
If there's no "simple enough" way to do minimal timezones, then allow only GMT (and require using a suitable module to recognise any other TZ). If you really don't care because you know for sure the TZ will never matter, say "use timezone <GMT>". (You may as well not care that all the times are GMT in that case. But if it turns out someday that you do care, you can't say you didn't know.)
Or maybe allow any string as a timezone by default. If all your times use the same TZ, that's fine; but as soon as you try to work with two times with different zones, you'll get an error, unless you're using a module that knows how to convert between those zones.
(While we're at it, why is "time zone" still officially two words? Usually I like to side with the dictionary, but I can't figure out how "timezone" has escaped becoming de facto standard English.)
((I also prefer "Instant" to "DateTime" unless we end up using both, as in Darren Duncan's suggestion.))
-David
