On Mon, May 26, 2014 at 11:12 AM, Louis LaBrunda
<Lou at keystone-software.com> wrote:
> On Mon, 26 May 2014 17:29:19 +0200, Bert Freudenberg <bert at freudenbergs.de>
> 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:
>>>>
>>>> On Sun, 25 May 2014 13:48:44 -0400, "David T. Lewis" <lewis at mail.msen.com>
>>>> wrote:
>>>>
>>>>> I have been working on a variation of class DateAndTime that replaces its
>>>>> instance variables (seconds offset jdn nanos) with two instance variables,
>>>>> utcMicroseconds to represent microseconds elapsed since the Posix epoch, and
>>>>> localOffsetSeconds to represent the local time zone offset. When instantiating
>>>>> the time now, A single call primitiveUtcWithOffset is used to obtain these
>>>>> two values atomically as reported by the underlying platform.
>>>>>
>>>>> There are several advantages to this representation of DateAndTime, the most
>>>>> important of which is that its magnitude is unambiguous regardless of daylight
>>>>> savings transitions in local time zones.
>>>>>
>>>> Hi Dave,
>>>>
>>>> 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.
>>- Bert -
>
> I guess a DateAndTime class (without offset) could always answer 0 for the
> offset and a DateAndTimeWithOffset subclass could carry and answer the
> offset.  Methods could be provided to morph one into the other if desired.

No, one of the core requirements of a DateAndTime has always been to
be able to answer the local time.  It's fine for its internal
representation to be in UTC, but that requirement cannot go away.

If you want all UTC DateAndTime's then just specify an offset of 0.