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?

Thanks,
cbc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170313/2f2db9be/attachment.html>