UnixTime

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

UnixTime

Edgar De Cleene
Fellows:
I found useful add UnixTime at the beginning of file names for you have
nnnFoo.etc what is compatible with different OS and you easily see ordered .

But I my image I do not have how convert this value to DateAndTime again.
So i attach this just in case some could use it.



DateAndTime class-fromUnixTime.st (362 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UnixTime

Bert Freudenberg
Since we already have DateAndTime>>asUnixTime, having DateAndTime class>>fromUnixTime: seems like a reasonable addition. Thank you!

- Bert -

On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]> wrote:
Fellows:
I found useful add UnixTime at the beginning of file names for you have
nnnFoo.etc what is compatible with different OS and you easily see ordered .

But I my image I do not have how convert this value to DateAndTime again.
So i attach this just in case some could use it.






Reply | Threaded
Open this post in threaded view
|

Re: UnixTime

David T. Lewis
On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote:

>
> On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]>
> wrote:
>
> > Fellows:
> > I found useful add UnixTime at the beginning of file names for you have
> > nnnFoo.etc what is compatible with different OS and you easily see ordered
> > .
> >
> > But I my image I do not have how convert this value to DateAndTime again.
> > So i attach this just in case some could use it.
> >
>
> Since we already have DateAndTime>>asUnixTime, having DateAndTime
> class>>fromUnixTime: seems like a reasonable addition. Thank you!
>
> - Bert -

Edgar's enhancement looks good to me also, but unfortunately it does not
work due to a problem in DateAndTime class>>fromSeconds:, which is supposed
to do this:

   DateAndTime class>>fromSeconds: seconds
       "Answer a DateAndTime since the Squeak epoch: 1 January 1901"


If we agree that the Squeak epoch was supposed to have been defined relative
to UTC, then #fromSeconds: is broken because it treats its argument as
seconds since the "local Squeak epoch" (early Squeak VMs were built upon
the faulty premise of using local time).

Because of this problem in #fromSeconds: we get the following (I am five
hours from GMT):

   dt1 := DateAndTime now.
   unixSeconds1 := dt1 asUnixTime.
   dt2 := DateAndTime fromUnixTime: unixSeconds1.
   unixSeconds2 := dt2 asUnixTime.
   dt2 - dt1. ==> 0:04:59:59.890588
   unixSeconds2 - unixSeconds1. ==> 18000

IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds:
so that the argument is interpreted as seconds since the UTC Smalltalk epoch.

<OT>
Note also that #asUnixTime truncates (or rounds?) to a whole second, which is
reasonable given that Unix time(2) does the same thing. But it might deserve
a method comment if that is the intended behavior. If the method was named
#asPosixTime, then I might argue that the value should not be rounded or
truncated.
</OT>

Dave


Reply | Threaded
Open this post in threaded view
|

Re: UnixTime

Edgar De Cleene
I use a forked Squeak 4.5 
If i do 
DateAndTime today 2016-11-20T00:00:00+01:00
DateAndTime today asUnixTime 1479596400
DateAndTime fromUnixTime: 1479596400 2016-11-19T23:00:00+01:00

The intended use is for put it in FileName compatible to all OS

1479596400NameOfFile.extension

An example

Parsing the links and convert the html to objects
Then saving this objects gives

1477612800Environment initialize.obj
1477612800Environment withName aName.obj
1477612800Environment.obj
1478131200JSON.obj
1478131200SIXX.obj
1478131200STON.obj
1478476800Monticello Basics.obj
1478563200Seaside status November 2016.obj
1478563200Seaside.obj

If you do( DateAndTime fromUnixTime:1478563200) asDate gives 8 November 2016
I understand you point but the current implementation is enough to me.

Edgar

On Nov 20, 2016, at 01:12, David T. Lewis <[hidden email]> wrote:

On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote:

On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]>
wrote:

Fellows:
I found useful add UnixTime at the beginning of file names for you have
nnnFoo.etc what is compatible with different OS and you easily see ordered
.

But I my image I do not have how convert this value to DateAndTime again.
So i attach this just in case some could use it.


Since we already have DateAndTime>>asUnixTime, having DateAndTime
class>>fromUnixTime: seems like a reasonable addition. Thank you!

- Bert -

Edgar's enhancement looks good to me also, but unfortunately it does not
work due to a problem in DateAndTime class>>fromSeconds:, which is supposed
to do this:

  DateAndTime class>>fromSeconds: seconds
      "Answer a DateAndTime since the Squeak epoch: 1 January 1901"


If we agree that the Squeak epoch was supposed to have been defined relative
to UTC, then #fromSeconds: is broken because it treats its argument as
seconds since the "local Squeak epoch" (early Squeak VMs were built upon
the faulty premise of using local time).

Because of this problem in #fromSeconds: we get the following (I am five
hours from GMT):

  dt1 := DateAndTime now.
  unixSeconds1 := dt1 asUnixTime.
  dt2 := DateAndTime fromUnixTime: unixSeconds1.
  unixSeconds2 := dt2 asUnixTime.
  dt2 - dt1. ==> 0:04:59:59.890588
  unixSeconds2 - unixSeconds1. ==> 18000

IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds:
so that the argument is interpreted as seconds since the UTC Smalltalk epoch.

<OT>
Note also that #asUnixTime truncates (or rounds?) to a whole second, which is
reasonable given that Unix time(2) does the same thing. But it might deserve
a method comment if that is the intended behavior. If the method was named
#asPosixTime, then I might argue that the value should not be rounded or
truncated.
</OT>

Dave





Reply | Threaded
Open this post in threaded view
|

Re: UnixTime

Levente Uzonyi
In reply to this post by David T. Lewis
We use [DateAndTime unixEpoch + 1479647248 seconds] whenever we need such
conversion. It's quicker and it also avoids the time zone issue of
#fromSeconds:.

Levente

On Sat, 19 Nov 2016, David T. Lewis wrote:

> On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote:
>>
>> On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]>
>> wrote:
>>
>> > Fellows:
>> > I found useful add UnixTime at the beginning of file names for you have
>> > nnnFoo.etc what is compatible with different OS and you easily see ordered
>> > .
>> >
>> > But I my image I do not have how convert this value to DateAndTime again.
>> > So i attach this just in case some could use it.
>> >
>>
>> Since we already have DateAndTime>>asUnixTime, having DateAndTime
>> class>>fromUnixTime: seems like a reasonable addition. Thank you!
>>
>> - Bert -
>
> Edgar's enhancement looks good to me also, but unfortunately it does not
> work due to a problem in DateAndTime class>>fromSeconds:, which is supposed
> to do this:
>
>   DateAndTime class>>fromSeconds: seconds
>       "Answer a DateAndTime since the Squeak epoch: 1 January 1901"
>
>
> If we agree that the Squeak epoch was supposed to have been defined relative
> to UTC, then #fromSeconds: is broken because it treats its argument as
> seconds since the "local Squeak epoch" (early Squeak VMs were built upon
> the faulty premise of using local time).
>
> Because of this problem in #fromSeconds: we get the following (I am five
> hours from GMT):
>
>   dt1 := DateAndTime now.
>   unixSeconds1 := dt1 asUnixTime.
>   dt2 := DateAndTime fromUnixTime: unixSeconds1.
>   unixSeconds2 := dt2 asUnixTime.
>   dt2 - dt1. ==> 0:04:59:59.890588
>   unixSeconds2 - unixSeconds1. ==> 18000
>
> IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds:
> so that the argument is interpreted as seconds since the UTC Smalltalk epoch.
>
> <OT>
> Note also that #asUnixTime truncates (or rounds?) to a whole second, which is
> reasonable given that Unix time(2) does the same thing. But it might deserve
> a method comment if that is the intended behavior. If the method was named
> #asPosixTime, then I might argue that the value should not be rounded or
> truncated.
> </OT>
>
> Dave

Reply | Threaded
Open this post in threaded view
|

Re: UnixTime

Chris Muller-3
In reply to this post by David T. Lewis
I don't agree that the Squeak epoch was "supposed" to have been
defined relative to UTC.  Its just a number, it don't see that it
matters when or what number we start with, as long as it satisfies its
requirement of being a numerical representation, and we don't change
it.  Changing it would be breaking it for all applications which ever
used it.

On Sat, Nov 19, 2016 at 10:12 PM, David T. Lewis <[hidden email]> wrote:

> On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote:
>>
>> On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]>
>> wrote:
>>
>> > Fellows:
>> > I found useful add UnixTime at the beginning of file names for you have
>> > nnnFoo.etc what is compatible with different OS and you easily see ordered
>> > .
>> >
>> > But I my image I do not have how convert this value to DateAndTime again.
>> > So i attach this just in case some could use it.
>> >
>>
>> Since we already have DateAndTime>>asUnixTime, having DateAndTime
>> class>>fromUnixTime: seems like a reasonable addition. Thank you!
>>
>> - Bert -
>
> Edgar's enhancement looks good to me also, but unfortunately it does not
> work due to a problem in DateAndTime class>>fromSeconds:, which is supposed
> to do this:
>
>    DateAndTime class>>fromSeconds: seconds
>        "Answer a DateAndTime since the Squeak epoch: 1 January 1901"
>
>
> If we agree that the Squeak epoch was supposed to have been defined relative
> to UTC, then #fromSeconds: is broken because it treats its argument as
> seconds since the "local Squeak epoch" (early Squeak VMs were built upon
> the faulty premise of using local time).
>
> Because of this problem in #fromSeconds: we get the following (I am five
> hours from GMT):
>
>    dt1 := DateAndTime now.
>    unixSeconds1 := dt1 asUnixTime.
>    dt2 := DateAndTime fromUnixTime: unixSeconds1.
>    unixSeconds2 := dt2 asUnixTime.
>    dt2 - dt1. ==> 0:04:59:59.890588
>    unixSeconds2 - unixSeconds1. ==> 18000
>
> IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds:
> so that the argument is interpreted as seconds since the UTC Smalltalk epoch.
>
> <OT>
> Note also that #asUnixTime truncates (or rounds?) to a whole second, which is
> reasonable given that Unix time(2) does the same thing. But it might deserve
> a method comment if that is the intended behavior. If the method was named
> #asPosixTime, then I might argue that the value should not be rounded or
> truncated.
> </OT>
>
> Dave
>
>

Reply | Threaded
Open this post in threaded view
|

Re: UnixTime

Eliot Miranda-2


> On Nov 20, 2016, at 12:45 PM, Chris Muller <[hidden email]> wrote:
>
> I don't agree that the Squeak epoch was "supposed" to have been
> defined relative to UTC.  Its just a number, it don't see that it
> matters when or what number we start with, as long as it satisfies its
> requirement of being a numerical representation, and we don't change
> it.  Changing it would be breaking it for all applications which ever
> used it.

+1.  And also requiring vm mods and breaking vm backward compatibility.  IIABDFI.

_,,,^..^,,,_ (phone)

>
>> On Sat, Nov 19, 2016 at 10:12 PM, David T. Lewis <[hidden email]> wrote:
>>> On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote:
>>>
>>> On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]>
>>> wrote:
>>>
>>>> Fellows:
>>>> I found useful add UnixTime at the beginning of file names for you have
>>>> nnnFoo.etc what is compatible with different OS and you easily see ordered
>>>> .
>>>>
>>>> But I my image I do not have how convert this value to DateAndTime again.
>>>> So i attach this just in case some could use it.
>>>>
>>>
>>> Since we already have DateAndTime>>asUnixTime, having DateAndTime
>>> class>>fromUnixTime: seems like a reasonable addition. Thank you!
>>>
>>> - Bert -
>>
>> Edgar's enhancement looks good to me also, but unfortunately it does not
>> work due to a problem in DateAndTime class>>fromSeconds:, which is supposed
>> to do this:
>>
>>   DateAndTime class>>fromSeconds: seconds
>>       "Answer a DateAndTime since the Squeak epoch: 1 January 1901"
>>
>>
>> If we agree that the Squeak epoch was supposed to have been defined relative
>> to UTC, then #fromSeconds: is broken because it treats its argument as
>> seconds since the "local Squeak epoch" (early Squeak VMs were built upon
>> the faulty premise of using local time).
>>
>> Because of this problem in #fromSeconds: we get the following (I am five
>> hours from GMT):
>>
>>   dt1 := DateAndTime now.
>>   unixSeconds1 := dt1 asUnixTime.
>>   dt2 := DateAndTime fromUnixTime: unixSeconds1.
>>   unixSeconds2 := dt2 asUnixTime.
>>   dt2 - dt1. ==> 0:04:59:59.890588
>>   unixSeconds2 - unixSeconds1. ==> 18000
>>
>> IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds:
>> so that the argument is interpreted as seconds since the UTC Smalltalk epoch.
>>
>> <OT>
>> Note also that #asUnixTime truncates (or rounds?) to a whole second, which is
>> reasonable given that Unix time(2) does the same thing. But it might deserve
>> a method comment if that is the intended behavior. If the method was named
>> #asPosixTime, then I might argue that the value should not be rounded or
>> truncated.
>> </OT>
>>
>> Dave
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: UnixTime

David T. Lewis
On Sun, Nov 20, 2016 at 01:04:07PM -0800, Eliot Miranda wrote:

>
>
> > On Nov 20, 2016, at 12:45 PM, Chris Muller <[hidden email]> wrote:
> >
> > I don't agree that the Squeak epoch was "supposed" to have been
> > defined relative to UTC.  Its just a number, it don't see that it
> > matters when or what number we start with, as long as it satisfies its
> > requirement of being a numerical representation, and we don't change
> > it.  Changing it would be breaking it for all applications which ever
> > used it.
>
> +1.  And also requiring vm mods and breaking vm backward compatibility.  IIABDFI.

Um, no.

Eliot, I think that you have previously explained that the Smalltalk epoch was
intended to refer to 1 January 1901 GMT. That is a good thing because it makes
sense, and also because the earlier implementations of Squeak and the VM were
based on local time, which makes no sense at all.

I was not suggesting any change with regard to this definition, and I was not
suggesting any changes to the VM.

What I am saying is that DateAndTime class>>fromSeconds: is broken because
it's method comment says "Answer a DateAndTime since the Squeak epoch", and
its implementation does not do that.

Dave

>
> _,,,^..^,,,_ (phone)
> >
> >> On Sat, Nov 19, 2016 at 10:12 PM, David T. Lewis <[hidden email]> wrote:
> >>> On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote:
> >>>
> >>> On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]>
> >>> wrote:
> >>>
> >>>> Fellows:
> >>>> I found useful add UnixTime at the beginning of file names for you have
> >>>> nnnFoo.etc what is compatible with different OS and you easily see ordered
> >>>> .
> >>>>
> >>>> But I my image I do not have how convert this value to DateAndTime again.
> >>>> So i attach this just in case some could use it.
> >>>>
> >>>
> >>> Since we already have DateAndTime>>asUnixTime, having DateAndTime
> >>> class>>fromUnixTime: seems like a reasonable addition. Thank you!
> >>>
> >>> - Bert -
> >>
> >> Edgar's enhancement looks good to me also, but unfortunately it does not
> >> work due to a problem in DateAndTime class>>fromSeconds:, which is supposed
> >> to do this:
> >>
> >>   DateAndTime class>>fromSeconds: seconds
> >>       "Answer a DateAndTime since the Squeak epoch: 1 January 1901"
> >>
> >>
> >> If we agree that the Squeak epoch was supposed to have been defined relative
> >> to UTC, then #fromSeconds: is broken because it treats its argument as
> >> seconds since the "local Squeak epoch" (early Squeak VMs were built upon
> >> the faulty premise of using local time).
> >>
> >> Because of this problem in #fromSeconds: we get the following (I am five
> >> hours from GMT):
> >>
> >>   dt1 := DateAndTime now.
> >>   unixSeconds1 := dt1 asUnixTime.
> >>   dt2 := DateAndTime fromUnixTime: unixSeconds1.
> >>   unixSeconds2 := dt2 asUnixTime.
> >>   dt2 - dt1. ==> 0:04:59:59.890588
> >>   unixSeconds2 - unixSeconds1. ==> 18000
> >>
> >> IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds:
> >> so that the argument is interpreted as seconds since the UTC Smalltalk epoch.
> >>
> >> <OT>
> >> Note also that #asUnixTime truncates (or rounds?) to a whole second, which is
> >> reasonable given that Unix time(2) does the same thing. But it might deserve
> >> a method comment if that is the intended behavior. If the method was named
> >> #asPosixTime, then I might argue that the value should not be rounded or
> >> truncated.
> >> </OT>
> >>
> >> Dave
> >>
> >>
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: UnixTime

Levente Uzonyi
In reply to this post by Chris Muller-3
On Sun, 20 Nov 2016, Chris Muller wrote:

> I don't agree that the Squeak epoch was "supposed" to have been
> defined relative to UTC.  Its just a number, it don't see that it

Do you mean that it shouldn't have any time zone defined?
If yes, then it is so ambiguous that we should look for another epoch.

(The current ambiguity makes me implement new time classes whenever it's
relevant.)

> matters when or what number we start with, as long as it satisfies its
> requirement of being a numerical representation, and we don't change
> it.  Changing it would be breaking it for all applications which ever
> used it.

So, when these time stamps are created on different machines in different
time zones at the same time, then it's perfectly okay to have different
numbers?

Levente

>
> On Sat, Nov 19, 2016 at 10:12 PM, David T. Lewis <[hidden email]> wrote:
>> On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote:
>>>
>>> On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]>
>>> wrote:
>>>
>>> > Fellows:
>>> > I found useful add UnixTime at the beginning of file names for you have
>>> > nnnFoo.etc what is compatible with different OS and you easily see ordered
>>> > .
>>> >
>>> > But I my image I do not have how convert this value to DateAndTime again.
>>> > So i attach this just in case some could use it.
>>> >
>>>
>>> Since we already have DateAndTime>>asUnixTime, having DateAndTime
>>> class>>fromUnixTime: seems like a reasonable addition. Thank you!
>>>
>>> - Bert -
>>
>> Edgar's enhancement looks good to me also, but unfortunately it does not
>> work due to a problem in DateAndTime class>>fromSeconds:, which is supposed
>> to do this:
>>
>>    DateAndTime class>>fromSeconds: seconds
>>        "Answer a DateAndTime since the Squeak epoch: 1 January 1901"
>>
>>
>> If we agree that the Squeak epoch was supposed to have been defined relative
>> to UTC, then #fromSeconds: is broken because it treats its argument as
>> seconds since the "local Squeak epoch" (early Squeak VMs were built upon
>> the faulty premise of using local time).
>>
>> Because of this problem in #fromSeconds: we get the following (I am five
>> hours from GMT):
>>
>>    dt1 := DateAndTime now.
>>    unixSeconds1 := dt1 asUnixTime.
>>    dt2 := DateAndTime fromUnixTime: unixSeconds1.
>>    unixSeconds2 := dt2 asUnixTime.
>>    dt2 - dt1. ==> 0:04:59:59.890588
>>    unixSeconds2 - unixSeconds1. ==> 18000
>>
>> IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds:
>> so that the argument is interpreted as seconds since the UTC Smalltalk epoch.
>>
>> <OT>
>> Note also that #asUnixTime truncates (or rounds?) to a whole second, which is
>> reasonable given that Unix time(2) does the same thing. But it might deserve
>> a method comment if that is the intended behavior. If the method was named
>> #asPosixTime, then I might argue that the value should not be rounded or
>> truncated.
>> </OT>
>>
>> Dave
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: UnixTime

David T. Lewis
On Mon, Nov 21, 2016 at 01:11:46AM +0100, Levente Uzonyi wrote:

> On Sun, 20 Nov 2016, Chris Muller wrote:
>
> >I don't agree that the Squeak epoch was "supposed" to have been
> >defined relative to UTC.  Its just a number, it don't see that it
>
> Do you mean that it shouldn't have any time zone defined?
> If yes, then it is so ambiguous that we should look for another epoch.
>
> (The current ambiguity makes me implement new time classes whenever it's
> relevant.)

Which reminds me ... I would still welcome feedback on www.squeaksource.com/UTCDateAndTime,
which can be loaded into a 64-bit trunk Spur image like this:

  (Installer ss project: 'UTCDateAndTime') install: 'Chronology-Core-dtl.3.mcz'. "load starting mcz"
  (MCMcmUpdater updateMapNamed: 'update' repository: 'http://www.squeaksource.com/UTCDateAndTime') doUpdate: false.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: UnixTime

Chris Muller-4
In reply to this post by Levente Uzonyi
I may have misunderstood; I thought it was defined in terms of a particular timezone and that the proposal was simply to shift it in order to line up with UTC.  I thought it was simply a naming / conversion issue balanced against legacy compatibility; I didn't think about the more serious ambiguity issue you pointed out.

So then there may be no way to avoid changing the legacy method, but that question always deserves to be asked; "is there a compatible way to address it?"

Best,
  Chris


I don't agree that the Squeak epoch was "supposed" to have been
defined relative to UTC.  Its just a number, it don't see that it

Do you mean that it shouldn't have any time zone defined?
If yes, then it is so ambiguous that we should look for another epoch. 

(The current ambiguity makes me implement new time classes whenever it's relevant.)

matters when or what number we start with, as long as it satisfies its
requirement of being a numerical representation, and we don't change
it.  Changing it would be breaking it for all applications which ever
used it.

So, when these time stamps are created on different machines in different time zones at the same time, then it's perfectly okay to have different numbers?

Levente


On Sat, Nov 19, 2016 at 10:12 PM, David T. Lewis <[hidden email]> wrote:
On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote:

On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]>
wrote:

> Fellows:
> I found useful add UnixTime at the beginning of file names for you have
> nnnFoo.etc what is compatible with different OS and you easily see ordered
> .
>
> But I my image I do not have how convert this value to DateAndTime again.
> So i attach this just in case some could use it.
>

Since we already have DateAndTime>>asUnixTime, having DateAndTime
class>>fromUnixTime: seems like a reasonable addition. Thank you!

- Bert -

Edgar's enhancement looks good to me also, but unfortunately it does not
work due to a problem in DateAndTime class>>fromSeconds:, which is supposed
to do this:

   DateAndTime class>>fromSeconds: seconds
       "Answer a DateAndTime since the Squeak epoch: 1 January 1901"


If we agree that the Squeak epoch was supposed to have been defined relative
to UTC, then #fromSeconds: is broken because it treats its argument as
seconds since the "local Squeak epoch" (early Squeak VMs were built upon
the faulty premise of using local time).

Because of this problem in #fromSeconds: we get the following (I am five
hours from GMT):

   dt1 := DateAndTime now.
   unixSeconds1 := dt1 asUnixTime.
   dt2 := DateAndTime fromUnixTime: unixSeconds1.
   unixSeconds2 := dt2 asUnixTime.
   dt2 - dt1. ==> 0:04:59:59.890588
   unixSeconds2 - unixSeconds1. ==> 18000

IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds:
so that the argument is interpreted as seconds since the UTC Smalltalk epoch.

<OT>
Note also that #asUnixTime truncates (or rounds?) to a whole second, which is
reasonable given that Unix time(2) does the same thing. But it might deserve
a method comment if that is the intended behavior. If the method was named
#asPosixTime, then I might argue that the value should not be rounded or
truncated.
</OT>

Dave





Reply | Threaded
Open this post in threaded view
|

Re: UnixTime

Eliot Miranda-2


On Nov 20, 2016, at 8:14 PM, Chris Muller <[hidden email]> wrote:

I may have misunderstood; I thought it was defined in terms of a particular timezone and that the proposal was simply to shift it in order to line up with UTC.  I thought it was simply a naming / conversion issue balanced against legacy compatibility; I didn't think about the more serious ambiguity issue you pointed out.

So then there may be no way to avoid changing the legacy method, but that question always deserves to be asked; "is there a compatible way to address it?"

keep fromSeconds: interpreting its argument as local seconds and add fromUTCSeconds: which interprets its argument as local second.


Best,
  Chris


I don't agree that the Squeak epoch was "supposed" to have been
defined relative to UTC.  Its just a number, it don't see that it

Do you mean that it shouldn't have any time zone defined?
If yes, then it is so ambiguous that we should look for another epoch. 

(The current ambiguity makes me implement new time classes whenever it's relevant.)

matters when or what number we start with, as long as it satisfies its
requirement of being a numerical representation, and we don't change
it.  Changing it would be breaking it for all applications which ever
used it.

So, when these time stamps are created on different machines in different time zones at the same time, then it's perfectly okay to have different numbers?

Levente


On Sat, Nov 19, 2016 at 10:12 PM, David T. Lewis <[hidden email]> wrote:
On Fri, Nov 18, 2016 at 07:01:29PM +0100, Bert Freudenberg wrote:

On Fri, Nov 18, 2016 at 2:16 PM, Edgar De Cleene <[hidden email]>
wrote:

> Fellows:
> I found useful add UnixTime at the beginning of file names for you have
> nnnFoo.etc what is compatible with different OS and you easily see ordered
> .
>
> But I my image I do not have how convert this value to DateAndTime again.
> So i attach this just in case some could use it.
>

Since we already have DateAndTime>>asUnixTime, having DateAndTime
class>>fromUnixTime: seems like a reasonable addition. Thank you!

- Bert -

Edgar's enhancement looks good to me also, but unfortunately it does not
work due to a problem in DateAndTime class>>fromSeconds:, which is supposed
to do this:

   DateAndTime class>>fromSeconds: seconds
       "Answer a DateAndTime since the Squeak epoch: 1 January 1901"


If we agree that the Squeak epoch was supposed to have been defined relative
to UTC, then #fromSeconds: is broken because it treats its argument as
seconds since the "local Squeak epoch" (early Squeak VMs were built upon
the faulty premise of using local time).

Because of this problem in #fromSeconds: we get the following (I am five
hours from GMT):

   dt1 := DateAndTime now.
   unixSeconds1 := dt1 asUnixTime.
   dt2 := DateAndTime fromUnixTime: unixSeconds1.
   unixSeconds2 := dt2 asUnixTime.
   dt2 - dt1. ==> 0:04:59:59.890588
   unixSeconds2 - unixSeconds1. ==> 18000

IMO, Edgar's method is correct and we should fix DateAndTime class>>fromSeconds:
so that the argument is interpreted as seconds since the UTC Smalltalk epoch.

<OT>
Note also that #asUnixTime truncates (or rounds?) to a whole second, which is
reasonable given that Unix time(2) does the same thing. But it might deserve
a method comment if that is the intended behavior. If the method was named
#asPosixTime, then I might argue that the value should not be rounded or
truncated.
</OT>

Dave