On 2009-Feb-20, at 7:17 am, Dave Rolsky wrote:
Define really basic math. [...] you could say "all math is done in
terms of seconds", but then there's literally no way to "add 1 month".
Oh, I meant only adding or subtracting seconds (as mentioned
elsewhere); adding a month is certainly advanced enough to require a
module.
I also think some really basic parsing would be suitable -- no more
than the ability to understand strings in the same default ISO format
used for displaying dates and times, e.g.
my Temporal::Date $christmas = "2009-12-25";
As I said in the spec, you _can_ get an observance for a given epoch
value quite easily. This tells you the offset from UTC, whether DST
is in effect, and a short name identifier (like CST).
OK, but I wasn't sure how required it was -- shouldn't there be
something to disallow an undefined observance? And plain Date or Time
objects don't have a TZ observance at all.
I can see that a time or date might not have a specific timezone, such
as Dates for a calendar program; you'd want to be able to highlight a
certain day, not a range of 24 hours that shifted as you changed
timezones. But that's really a floating or lazy local TZ; the zone is
defined at any given moment, it just might change if the (effective)
location of the computer changes.
That's still different from having no TZ info at all... although using
undef to represent that floating value seems reasonable. I would
still argue that however it's represented, it should be necessary to
specify a fixed TZ or some special value for the floating zone.
On 2009-Feb-20, at 10:01 am, Mark J. Reed wrote:
Why can't we just have time() that takes a :tz adverb and dispense
with gmtime() and localtime()?
If an Instant object also represents a point in time irrespective of
location, then there's likewise no point in a :tz adverb.
Oh, of course, I was even thinking that the TZ would only be need to
be specified for times coming from somewhere else.
-David
