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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170313/62834768/attachment.html>