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.


Reply via email to