I see you already committed a patch.  TimeStamp will be going away in 4.5.

 - Chris



On Sun, Nov 4, 2012 at 8:55 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> We have two test failures related to time zone offset handling:
>
>   TimeStampTest>>testFromSeconds
>   TimeStampTest>>testReadFromA1
>
> In #testFromSeconds, we compare a TimeStamp created from an integer seconds
> to another TimeStamp created from strings. They are intended to refer to
> the "same" time stamp, but one has a time zone offset and the other has
> the offset set to zero (UTC), more or less like this:
>
>   tsFromStrings := TimeStamp date: ('1-10-2000' asDate) time: ('11:55:00 am' asTime).
>   tsFromStrings. ==> 10 January 2000 11:55 am
>   tsFromStrings offset. ==> 0:00:00:00
>
>   tsFromIntegerSeconds := TimeStamp fromSeconds: 3124958100.
>   tsFromIntegerSeconds. ==> 10 January 2000 11:55 am
>   tsFromIntegerSeconds offset. ==> 0:01:00:00
>
> I believe that the discrepancy is related to the change we did in trunk here:
>
>   Name: Kernel-cmm.671
>   Author: cmm
>   Time: 10 February 2012, 4:58:49.106 pm
>
>   Decided against the localized vs. globalized mode.  Timespans created in
>   the context of an offset will start in that offset.  When no context is
>   available, the defaultOffset for Timespans must be zero.  For example,
>   two ways to make a Date for today:
>      Date today.  'start is midnight at offset zero.  Will compare
>      successfully to other Date today results.'
>
>      DateAndTime now asDate.  'In this case, the start is midnight of the
>      local time-zone.  It can only compare equally to Dates of its time-zone.'
>
> I am not sure how this should be handled. Chris, can you comment?
>
> Thanks,
> Dave
>
>