Hi Chris,

On Mon, Jun 27, 2016 at 8:31 AM, Chris Cunningham <cunningham.cb at gmail.com>
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.
>
> 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?
>

That's what I wonder.  Can't we simply store the start time (ideally UTC
microseconds or local microseconds) internally and then compute the
duration programmatically, depending on the timezone in effect?


>
> 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.
>

So if we store the start time isn't the conversion to a magnitude simply an
inst var access?


> -cbc
>
> 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 -
>>
>>
>>
>>
>>
>
>
>
>


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