Thanks all!  I always used DateAndTime previously, but thought about 
using TimeStamp instead for a new project.  I will rethink that and go 
back to DateAndTime.

Best,
Tim

On 2018-04-02 11:19, Chris Cunningham wrote:

> On Mon, Apr 2, 2018 at 8:59 AM, Levente Uzonyi <leves at caesar.elte.hu> 
> wrote:
> 
>> Don't use TimeStamp. I see several issues which break your snippet:
>> 1) #printOn: and #storeOn: ignore time zone information (offset).
>> 2) Class side #readFrom: ignores time zone information (offset).
>> 3) Class side #readFrom: can not fully parse the output of #storeOn:. 
>> It seems to only work by accident.
>> 4) It's a subclass of DateAndTime, but it seems to add noting 
>> generally useful. Based on the class comment, it has the same purpose 
>> as DateAndTime, but that's not the case.
> 
> Seconded - don't use TimeStamp.  It did exist before DateAndTime, then 
> was moved to a subclass to ease porting.
> Besides the reasons Levente gave, a few external packages (on 
> SqueakMap/SqueakSource) contain TimeStamp extensions and/or 
> redefinition that really, really mess up with the current definition.  
> If you get unlucky enough to load one of these and you are using 
> TimeStamp, things stop working (or mostly work while corrupting your 
> data).
> 
> -cbc
> So, use DateAndTime instead:
> 
> | t1 t2 s |
> t1 := DateAndTime now.
> s := String streamContents: [:stream | t1 storeOn: stream ].
> t2 := Compiler evaluate: s.
> { t1 offset. t2 offset. t1 = t2 } "==> {0:02:00:00 . 0:02:00:00 . 
> true}"
> 
> Levente
> 
> On Mon, 2 Apr 2018, Tim Johnson wrote:
> 
> Hi all,
> I noticed the following:
> 
> | t1 t2 s |
> t1 := TimeStamp now.
> s := String streamContents: [:stream | t1 storeOn: stream ].
> t2 := TimeStamp readFrom: s readStream.
> { t1 offset.  t2 offset.  t1 = t2 } printIt ->  {-0:07:00:00 . 
> 0:00:00:00 . false}
> 
> A web search turned up this thread from 2017:
> 
> http://forum.world.st/DateAndTime-offset-just-bit-me-td4938463.html
> 
> I'm wondering if there has been any resolution or if the situation is 
> the same:  I should try the fixes from UTCDateAndTime.
> 
> Happy to write a test if this is worth the effort.
> 
> Thanks,
> Tim