David Green wrote:
I don't like dates just starting at midnight because I've run into too
many awkward cases where $time < $date doesn't do what you mean because
it assumes 0:00:00 when you meant 23:59:59. I'd rather have dates
becomes time-ranges.
And not all midnights exist, because time
Dates starting at midnight is fine, but I agree that a Date shouldn't
automatically coerce into midnight on that date. If it's going to
autocoerce at all, I'd recommend noon instead, but better to force the
programmer to pick what they mean.
On Fri, Feb 20, 2009 at 2:32 AM, David Green wrote:
>
On 2009-Feb-19, at 4:39 pm, Martin Kealey wrote:
2. "Date isa Instant" works sensibly: anywhere that expects an
Instant, you
can give it a Date. (Assuming we all agree that dates start at
midnight, but
then we *are* talking specifically Gregorian dates.)
I don't like dates just starting at
On Fri, 20 Feb 2009, Timothy S. Nelson wrote:
> On Thu, 19 Feb 2009, Martin D Kealey wrote:
> > Rather, let's have immutable time "values", and methods which return other
> > "values" where various computations (*1) have been applied. Provide
> > constructors which take the Y/M/D/h/m/s/dst_now/dst_
Just to clear up ahead of time, the consensus both here and on IRC
seemed to be that in the core, we put a basic Temporal::Instant object that
about powerful enough to deal with:
- localtime/gmtime functionality
- ctime, mtime, etc, in stat()
- nanoseconds or whatever needed f
