Lots of database packages rely on variants of that class : TimeStamp and Timestamp...  Some packages even provide their own version !

It's always been a mess!


----------------- 
Benoît St-Jean 
Yahoo! Messenger: bstjean 
Twitter: @BenLeChialeux 
Pinterest: benoitstjean 
Instagram: Chef_Benito
IRC: lamneth 
Blogue: endormitoire.wordpress.com 
"A standpoint is an intellectual horizon of radius zero".  (A. Einstein) 

    On Tuesday, April 3, 2018, 9:14:20 a.m. EDT, Levente Uzonyi <leves at caesar.elte.hu> wrote:  
 
 Hi Eliot,

On Mon, 2 Apr 2018, Eliot Miranda wrote:

> Hi Levente,
>
>> On Apr 2, 2018, at 8:59 AM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>> 
>> Don't use TimeStamp.
>
> Can we deprecate it then?

Sure, but there are still users in the image. Mainly Monticello, SqueakMap 
Client and SUnit.
It will take some time to go through them and properly rewrite the code.

Levente

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