TimeStamp offsets

> 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 <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.

> On Mon, Apr 2, 2018 at 8:59 AM, Levente Uzonyi <[hidden email]>
> 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

> 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
>

> 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
> <[hidden email]> wrote:
>
>
> Hi Eliot,
>
> On Mon, 2 Apr 2018, Eliot Miranda wrote:
>
>> Hi Levente,
>>
>>> On Apr 2, 2018, at 8:59 AM, Levente Uzonyi <[hidden email]> 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
>>>
>
>
>
>

>On Wednesday 11 April 2018 03:45 AM, Benoit St-Jean via Squeak-dev wrote:
>> I was wondering if images for different platforms (Mac, Linux, Windows)
>> and VMs (32bit, 64bit) are, code-wise, the same?  By "the same", I mean
>> do they all have the exact same code base or some classes/methods are in
>> some and not in others or different?
>
>Short answer - Images yes, VMs no.
>
>"Squeak" without qualification refers to the image. The official release
>contains separate VMs for different platforms but only a single image.
>
>Squeak VM is different for each platform, but they do share the source
>code for bytecode interpreter, primitives and object manager and some
>(algorithmic) plugins. The launcher and device-based plugins (e.g.
>display) are host-specific.
>
>Generally, you should be able to save your image on Windows and resume
>it on a Linux or Mac without any issues. There may be minor irritants
>like differently configured CTRL/ALT/CMD keys or fonts but the overall
>experience is stunningly smooth.
>
>HTH .. Subbu
>