> On Nov 20, 2016, at 8:14 PM, Chris Muller <ma.chris.m at gmail.com> 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 <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
>>>> 
>>>> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20161121/9464a6f3/attachment.html>