Hi Levente,

On Tue, Mar 14, 2017 at 2:41 AM, Levente Uzonyi <leves at caesar.elte.hu>
wrote:

> Hi Eliot,
>
> I pointed out earlier that the time zone doesn't update in primitive 241
> or primitiveUtcWithOffset when DST changes happen.
> However, it does change in LocalePlugin's primitiveTimezoneOffset, which
> is what we use as a workaround to create correct DateAndTime instances in
> one of our projects.
> It would be nice if the other two primitives worked correctly.


Sure, but the point is that we don't want the normal time access primitive
to update the timezone in 241 because that adds overhead to every
invocation that pays off only twice a year.  As David points out
primitiveUtcWithOffset /does/ update the timezone.  So what's needed is a
way to arrange that primitiveUtcWithOffset is invoked often enough to
update the timezone, but infrequently enough not to cost a lot.


>
> Levente
>
>
> On Mon, 13 Mar 2017, Eliot Miranda wrote:
>
> Hi Chris,
>> On Mon, Mar 13, 2017 at 10:45 AM, Chris Cunningham <
>> cunningham.cb at gmail.com> wrote:
>>       Hi.
>> I routinely do a scan of various resources, and of the other properties
>> is an 'install date'.  I like to save these as DateAndTime, which of course
>> use offset to get the 'right' time.
>>
>> Well, just this past weekend my locale went into daylight savings time,
>> which means that my local offset changed.  Which also means that all of the
>> dates that I read in (such as install date) that also
>> changed to daylight time have had their offsets changed.
>>
>> I daily do a diff to see what has changed, and all of the install dates
>> have now been updated to a different offset, which causes a large amount of
>> noise that I need to wade through to see if anything
>> of interest actually changed.
>>
>> This is frustrating. Here is what I see DateAndTime working currently:
>> 1> For DateAndTime now, it get the current offset and applies it to the
>> DateAndTime.  This is as accurate as we are going to get (i.e., as long as
>> my current machine is accurate, this value will be
>> accurate).  Nice.
>> 2> For any other time, if you make a DateAndTime out of a string that has
>> a offset specified, it accurately create the right DateAndTime.  Also nice.
>> 3> For any other time that you make a DateAndTime out of a string that
>> doesn't have the offset specified (such as database values and system
>> timestamps from many utilities), you get the current off of
>> your machine stamped.  Definitely not nice.  For instance:
>>     DateAndTime now "==> 2017-03-13T08:57:36.772086-07:00"
>>     '2017-03-10 00:00:00' asDateAndTime "==> 2017-03-10T00:00:00-07:00"
>>     (that last one should be -08:00 offset)
>>
>> I'm trying to decide what to do about this.
>>
>> One option is to just keep the timestamps as strings - except they aren't
>> always in the same format, so I can't compare them (which gets me roughly
>> back to the same point).
>>
>> Another is to install one of the better date/time packages that uses the
>> Olson database to figure out what the current offset it, and have it deal
>> with those issues automatically.  Except that feels
>> like overkill for what I really want - a simple way to see if a date/time
>> changed.
>>
>> Another it to create a sibling class to DateAndTime that keeps the zone
>> (but not offset) - say Pacific Time instead of Pacific Standard Time or
>> Pacific Daylight Time.  And this would NOT include the
>> offset.  This would allow for quick, accurate comparisions, and if
>> (probably when) I need to compare to get hour differences, I could load one
>> of the other tools to figure out what the offset it for
>> each date/time and turn those into real, accurate DateAndTime instances
>> for that compare.
>>
>> So, does anyone else have these issues?  Is there a better option?
>>
>>
>> What bit me today was that when the clocks went back the image, which I'd
>> left running overnight, did not.  Consequent;y when it competed a timestamp
>> it computed a value an hour out up until I quit and
>> restarted the image.  The result was that the Slang Smalltalk-to-C
>> translator refused to output any code because the timestamp of the source
>> classes was an hour behind the timestamp of the generated source,
>> so it thought that generated source had already been generated.
>>
>> So the issue for me is that the time zone doesn't update when it should.
>> One solution would be to schedule a long-running process that would expire
>> when the next timezone change is anticipated.  Another
>> solution might be to have class side code in Delay  or Time periodically
>> check (once an hour?) for the timezone.
>>
>>       Thanks,
>> cbc
>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170314/ee01d8ed/attachment.html>