[squeak-dev] Class comment for Date mentions #localizedDates

David T. Lewis lewis at mail.msen.com
Tue Jun 28 04:40:59 UTC 2016


On Mon, Jun 27, 2016 at 08:31:28AM -0700, Chris Cunningham wrote:
> So, Time and Dates are hard.  When Date was a magnitude, it was easy.  Now
> that it is a duration, it is occassionally wrong.  Think about daylight
> savings time - at least one a year the day length is 25 hours, and once it
> is 23 hours (although in some places there are no Daylight Savings, so this
> isn't true, and in others, there are 2 switches, so it happens twice).  Our
> current implementation doesn't take this into account - which is reasonable
> because it is hard to take this into account without a lot of work.

Quite right. The concept of "one day" is ambiguous unless we know the
local time zone in which it if defined. DST transitions, and possibly also
handling of leap seconds, make it impossible to know the duration of one
day without also knowing the time zone in which that day is defined.

> 
> If we want to keep Date as a timespan (with rough correctness), maybe we
> could also add in Day (as a magnitude) to work like the old Date?

If we have Day and Date, then IMHO the Day class should represent duration,
and the Date class should represent magnitude.

> 
> For what it is worth, I spend >80% of my time working with
> dates/timestamps, trying to turn them into Magnitudes for manipulations.
> The other 20%, I really enjoy them as timespans with locales since I deal
> with times from around the world.  But the two uses are not quite easy to
> deal with - doable, just not quite intuitive.
> 
> -cbc

Based on your experience, do you think that it would make sense to have
two classes for Day and Date, where one represents date as duration, and
the other represents date as magnitude?

Dave


> 
> On Mon, Jun 27, 2016 at 3:41 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> 
> > On Mon, Jun 27, 2016 at 5:30 AM, David T. Lewis <lewis at mail.msen.com>
> > wrote:
> >
> >> 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?
> >>
> >
> > I think this is a very relevant question. We may have to distinguish a Day
> > from a Date.
> >
> > IMHO a birthday is a perfect example. It's defined by a day+month+year. If
> > I was traveling I would celebrate the birthday in local time, so the
> > generic "birthday" needs to compare equal to all the local dates
> > independent of time zone.
> >
> > This is how Dates worked before we made them Timespans (because they had
> > no time, and hence no time zone). And this is also how they worked after I
> > added the "nil" offset hack (which ignores the timezone). But it's a hack,
> > not a good design. I'm not entirely sure what a good design would look like
> > that also does not break old code.
> >
> > - Bert -
> >
> >
> >
> >
> >

> 



More information about the Squeak-dev mailing list