[squeak-dev] UnixTime

Levente Uzonyi leves at caesar.elte.hu
Mon Nov 21 00:11:46 UTC 2016


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 <lewis at mail.msen.com> 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
>>
>>


More information about the Squeak-dev mailing list