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 <edgardec2005 at gmail.com>
> 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