On Mon, May 26, 2014 at 05:29:19PM +0200, Bert Freudenberg wrote:
On 26.05.2014, at 17:16, David T. Lewis lewis@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