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 <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/20161120/e4404951/attachment.html>