On Sun, Nov 20, 2016 at 01:04:07PM -0800, Eliot Miranda wrote:
> 
> 
> > On Nov 20, 2016, at 12:45 PM, Chris Muller <asqueaker at gmail.com> 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
> > 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.
> 
> +1.  And also requiring vm mods and breaking vm backward compatibility.  IIABDFI.

Um, no.

Eliot, I think that you have previously explained that the Smalltalk epoch was
intended to refer to 1 January 1901 GMT. That is a good thing because it makes
sense, and also because the earlier implementations of Squeak and the VM were
based on local time, which makes no sense at all.

I was not suggesting any change with regard to this definition, and I was not
suggesting any changes to the VM.

What I am saying is that DateAndTime class>>fromSeconds: is broken because
it's method comment says "Answer a DateAndTime since the Squeak epoch", and
its implementation does not do that.

Dave

> 
> _,,,^..^,,,_ (phone)
> > 
> >> 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
> >> 
> >> 
> > 
>