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