On Mon, Jun 27, 2016 at 5:47 AM, Louis LaBrunda <Lou at keystone-software.com>
wrote:

> Hi Dave,
>
> Not that it matters too much to the Squeak world but a Date in VA
> Smalltalk is a Magnitude.
>
> I'm very glad you are trying to think all this data/time stuff through.  A
> while ago (like ten
> years) VA Smalltalk went from keeping time as an integer number of seconds
> to keeping them as
> milliseconds.  In and of itself that was fine but they changed #asSeconds
> from answering that
> number of seconds to answering a rounded number of milliseconds.  This
> broke some of my code as
> it made some time values (when represented as seconds) look like a time in
> the future.  IMHO
> rounding shouldn't be used unless it is needed just before a value is
> being displayed for
> humans.  That wasn't the case here and although many if not most people
> agreed with me, I
> didn't discover the change until it had been in place for a long time and
> Instantiations was
> reluctant to fix it.
>

I hope we can settle on representing them as microseconds.  Using
nanoseconds (the Microsoft granularity) shrinks their usable time span to
36 years if using 61-bit SmallIntegers, which is too short even if we use
the posix epoch, and horrible if we want to rebase things, e.g. at 2000 or
2001.  Keeping microseconds, which is the VM representation gives us
~36,000 years within the 61-bit SmallInteger range (- 2^60 - 2^60 - 1) in
64-bit Spur.  Using milliseconds throws away precision and introduces a
divide.   Multiplying, or worse still dividing, by 1000 n every
instantiation seems like a bad idea to me.


> Lou
>
>
> On Sun, 26 Jun 2016 23:30:35 -0400, "David T. Lewis" <lewis at mail.msen.com>
> wrote:
>
> >Hi Chris,
> >
> >I was really just trying to ask for a good class comment. The current
> >comment contains an error, and I used that as an excuse for raising the
> >question.
> >
> >I want to know the *meaning* of the Date class. And I would like the
> >class comment to say what it means. The meaning seems to have changed
> >considerably over the last ten or fifteen years as the implementations
> >have changed, and I think that it would be helpful if the current
> >definition could be stated as clearly as possible.
> >
> >
> >On Sat, Jun 25, 2016 at 07:34:02PM -0500, Chris Muller wrote:
> >> Hi Dave, Dates created as positions by default is the definitely the
> >> correct behavior.  The original Date implementation inherited the
> >> abstraction from Timespan of a custom duration starting at a
> >> particular DateAndTime.  While that is a fine for abstract Timespans,
> >> it turned out to be a bad idea for Dates, since the vast majority of
> >> the use of Dates are as positions, not spans.
> >
> >I am not sure what is meant by "Dates as positions". When I first read
> >this, I was thinking of "position relative to GMT" but on reading it
> >again I realized that it probably means "position on a continuum of date
> >values". Or maybe I am just completely confused (hence my plea for a
> >good class comment). Despite my confusion, my own best guess at the
> >current intended meaning of "Date" was in my original question below.
> >
> >A bit off topic, but is is worth asking:
> >If we really want to model Date as a position on a continuum of date
> >values, and if we think that the implementation of Date as a kind of
> >Timespan is not right, then shouldn't we just consider going back to
> >the earlier (Squeak 3.6 and earlier) implementation of Date as a
> Magnitude,
> >rather than Date as a Timespan?
> >
> >Dave
> >
> >>
> >> Check out the discussion surrounding Berts recent clarification of the
> >> implementation, where the timezone for Dates-as-positions is now set
> >> to nil, so the "localized" or "globalized" nomenclature can be removed
> >> from the comment.
> >>
> >>  - Chris
> >>
> >>
> >> On Thu, Jun 23, 2016 at 8:05 AM, David T. Lewis <lewis at mail.msen.com>
> wrote:
> >> > The class comment says:
> >> >
> >> >   Instances of Date are Timespans with duration of 1 day.
> >> >
> >> >   Their default creation assumes a start of midnight of UTC to
> provide the fast, globalized Dates out of the box.  The legacy behavior
> that creates Timezone-sensitive Dates can be used by sending
> #localizedDates.
> >> >
> >> >
> >> > I no longer see #localizedDates in the image, so I think the comment
> needs an update.
> >> >
> >> >
> >> > For reference, and earlier version of the class comment said this:
> >> >
> >> >   Instances of Date are Timespans with duration of 1 day.
> >> >   Their default creation assumes a start of midnight in the local
> time zone.
> >> >
> >> >
> >> > I am not sure what the comment should say, but I would be happy if it
> could
> >> > better convey the intended meaning of "Date" in addition to the
> explanation
> >> > about creating instances relative to UTC versus local time zone.
> >> >
> >> > My expectation would be that a Date is a Timespan with a start value
> set to
> >> > midnight in some time zone. The start value is a DateAndTime, and the
> offset
> >> > instance variable of that DateAndTime would reflect that time zone.
> >> >
> >> > I would therefore expect that a "globalized" Date is a special case
> of a Date
> >> > that was created with the start of the Timespan at midnight UTC,
> regardless
> >> > of the current local time zone. A "globalized" Date is no different
> from any
> >> > other Date, it is simply a Date that was created with time zone UTC.
> >> >
> >> > Is that right?
> >> >
> >> > Dave
> >> >
> >> >
> >
> --
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
>
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160627/b304493e/attachment.htm