On Mon, May 26, 2014 at 05:29:19PM +0200, Bert Freudenberg wrote:
> On 26.05.2014, at 17:16, David T. Lewis <lewis at mail.msen.com> wrote:
> > On Mon, May 26, 2014 at 10:48:16AM -0400, Louis LaBrunda wrote:
> >> 
> >> May I respectfully ask why localOffsetSeconds (to represent the local time
> >> zone offset) is needed?  It seems to me a UTC time is enough.  Is there
> >> really a need for the timezone offset the instance was created in?  Does
> >> every DateAndTime instance need to carry this offset around with it?  I
> >> would think the offset is only needed if one wants to display a date/time
> >> as a local value and then one could get the local offset from the VM or a
> >> program setting the user had previously supplied regardless of where the
> >> computer was setup to run.  I guess there might be some historic interest
> >> as to the timezone an instances (or many instances) was created in but one
> >> could just keep that as a separate value.
> > 
> > Hi Lou,
> > 
> > Good question. In fact, one of the reasons I like the UTC implementation is
> > that it helps clarify the two main responsibilities of DateAndTime. One is
> > to represent time as a magnitude (for duration calculation, etc). The other
> > is to display time in the frame of reference of a local time zone. It is not
> > at all clear to me that those two responsibilies belong in the same class.
> > 
> > Dave
> 
> We need to be able to distinguish between local and universal time. It would be rather inconvenient if asking a DateAndTime for e.g. the hour would not be made to answer the local hour. Arguably the local time offset could be moved to a subclass, but having a single DateAndTime class is appealing for simplicity reasons, too.
> 

One thing that seemed awkward to me was the question of how to implement #=. I
chose to let it be a comparison of just the utcMicroseconds magnitude, ignoring
the localOffsetSeconds. That may be the wrong thing to do, although if I think
about a DateAndTime as a magnitude, I expect that it should be true that one
instance is "greater than or: [equal to]" another when utcMicroseconds are equal,
regardless of the local offset.

Dave