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.

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com