TimeStamp offsets

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

TimeStamp offsets

Tim Johnson-2
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:


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




Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp offsets

David T. Lewis
On Mon, Apr 02, 2018 at 08:26:39AM -0700, 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 <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.


Hi Tim,

I would be very happy to see a few people try UTCDateAndTime. I think that
it makes time calculations and local offsets much easier to understand, and
it provides a good performance boost also.

I should warn you that I have not tried loading it fresh into the latest
trunk image in a while, so you may encounter problems. If so I'll fix
them (but not today, I'll be traveling).

Thanks,
Dave


Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp offsets

Levente Uzonyi
In reply to this post by Tim Johnson-2
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.

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

cbc
Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp offsets

cbc


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









Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp offsets

Tim Johnson-2
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 <[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

Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp offsets

Eliot Miranda-2
In reply to this post by Levente Uzonyi
Hi Levente,

> On Apr 2, 2018, at 8:59 AM, Levente Uzonyi <[hidden email]> wrote:
>
> Don't use TimeStamp.

Can we deprecate it then?

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

Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp offsets

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

Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp offsets

Squeak - Dev mailing list
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
>>


Reply | Threaded
Open this post in threaded view
|

Re: TimeStamp offsets

Chris Muller-3
Any elimination of TimeStamp should be accompanied by ensuring
backward compatibility with existing persistent instances in our own
Monticello database.  It'd be too infeasible to require a conversion
of all old mcz packages.

On Tue, Apr 3, 2018 at 5:57 PM, Benoit St-Jean via Squeak-dev
<[hidden email]> wrote:

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

Reply | Threaded
Open this post in threaded view
|

VMs, platforms and 32 vs 64bit

Squeak - Dev mailing list
In reply to this post by Squeak - Dev mailing list
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?


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


Reply | Threaded
Open this post in threaded view
|

Re: VMs, platforms and 32 vs 64bit

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

Reply | Threaded
Open this post in threaded view
|

VMs, platforms and 32 vs 64bit

Louis LaBrunda
Hi Benoît,

+1

I do some development on windows and copy the image to a Raspberry Pi running Linux.  I can't
test everything as my windows box doesn't have the GPIO pins of the Raspberry but that is to be
expected.

Lou


On Wed, 11 Apr 2018 12:53:37 +0530, K K Subbu <[hidden email]> wrote:

>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
>
--
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon


Reply | Threaded
Open this post in threaded view
|

Re: VMs, platforms and 32 vs 64bit

timrowledge


> On 11-04-2018, at 5:46 AM, Louis LaBrunda <[hidden email]> wrote:
>
> Hi Benoît,
>
> +1

Indeed - image files are identical across platforms and pretty much always have been. The only general issue when moving an image from one to another is if the writer has used implicit assumptions about a platform - the commonest I see is assuming the format of file names and carelessly using string concatenations and '/'' & '.' to assemble strings instead of proper file name objects.

>
> I do some development on windows and copy the image to a Raspberry Pi running Linux.  I can't
> test everything as my windows box doesn't have the GPIO pins of the Raspberry but that is to be
> expected.

Actually...
https://www.raspberrypi.org/blog/gpio-expander/

I'm fairly sure that you could also build the pigpio library to run on a pc/mac and talk to pretty much any actual Pi also running the pigpiod daemon.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
All programmers are playwrights and all computers are lousy actors.



Reply | Threaded
Open this post in threaded view
|

Re: VMs, platforms and 32 vs 64bit

Jecel Assumpcao Jr
In reply to this post by Squeak - Dev mailing list
Benoit St-Jean wrote on Tue, 10 Apr 2018 22:15:13 +0000 (UTC)
> 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?

All images that have been released for Squeak have been exactly the same
for all platforms. You can save your work on an ARM based Raspberry Pi
and continue it on a x86 Windows PC.

That said, there are a few classes that are specific to each platform.
See FileDirectory, for example, which has as subclasses
AcornFileDirectory, DosFileDirectory, MacFileDirectory,
MacHFSPlusFileDirectory and UnixFileDirectory. Your application should
normally only use the abstract class and the right class for your
particular platform will get called and this will more or less work for
the Pi to PC move I described above. I wrote "more or less" because
obviously open files would be a problem, but they wouldn't make sense on
a different machine in any case.

You could strip out the classes for the platforms you are not interested
in, but they are such a tiny part of the image it wouldn't be worth it.

The subclasses of KeyboardInputInterpreter  {MacRomanInputInterpreter .
NoInputInterpreter . WinShiftJISInputInterpreter .
MacShiftJISInputInterpreter . UnixEUCJPInputInterpreter .
UnixUTF8JPInputInterpreter . WinGB2312InputInterpreter .
WinKSX1001InputInterpreter . SymbolInputInterpreter .
CP1250InputInterpreter . ISO88592InputInterpreter .
MacUnicodeInputInterpreter . UTF32InputInterpreter .
UnicodeInputInterpreter . UTF32JPInputInterpreter .
UnixUnicodeInputInterpreter} are the only other platform specific parts
of the image I am aware of.

In the early days the official Squeak images included all the code
needed to generate the virtual machine. That has since been moved to a
separate package called VMMaker which you now have to load explicitly if
you want to. That has quite a bit of platform specific code.

-- Jecel