<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-27 1:21 GMT+02:00 Sean P. DeNigris <span dir="ltr"><<a href="mailto:sean@clipperadams.com" target="_blank">sean@clipperadams.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">David T. Lewis wrote<br>
<div class="">> the two main responsibilities of DateAndTime. One is<br>
> to represent time as a magnitude (for duration calculation, etc). The<br>
> other<br>
> is to display time in the frame of reference of a local time zone. It is<br>
> not<br>
> at all clear to me that those two responsibilies belong in the same class.<br>
<br>
</div>There is definitely something fishy with the combination. Consider Pharo's<br>
Date, which retroactively applies the current timezone to dates. This is bad<br>
because e.g.:<br>
'7/10/2014' asDate "evaluated the day before DST" ~= '7/10/2014' asDate<br>
"evaluated the day after DST"<br>
<br>
I created an issue, which has been sitting on the bug tracker. Here's an<br>
excerpt from the discussion<br>
(<a href="https://pharo.fogbugz.com/default.asp?12147#BugEvent.90264" target="_blank">https://pharo.fogbugz.com/default.asp?12147#BugEvent.90264</a>):<br>
<br></blockquote><div><br></div><div>For me, this is definitely a bug.<br></div><div>In current implementation, the date corresponding to a DST change should be either 23h or 25h long,<br>and this should not depend on active DST at the time you ask.<br>
<br></div><div>Of course, if we go into these complications, what to do when the DST rules change, but we ask for a Date anterior to the change?<br></div><div>Shall we store/maintain the DST rule history for each and every part of the world?<br>
<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I see that a particular location could reasonably be implied in a Date,<br>
> e.g. if we're saying that a treaty was signed on such and such a date, we<br>
> mean at the place where it was signed... it may have already been the next<br>
> day in another time zone.<br>
><br>
> Now, what is beyond doubt, is that the timezone that would be implied is<br>
> the timezone of the date itself, not an artifact of when the instance was<br>
> created. In my example, I create '11/12/2013' asDate, and it assumes my<br>
> timezone.<br>
> Since it's the summer in NY, that means -4 offset. Now, I evaluate<br>
> '11/12/2013' asDate again in December. Again it implies my timezone, the<br>
> offset of which has changed to -5! So now '11/12/2013' asDate (in NY) ~=<br>
> '11/12/2013' asDate (in NY). Even though the offset of the date in<br>
> question, which depends only on whether DST was in effect on 11/12/2013,<br>
> has not changed.<br>
><br>
> So the current behavior of two equal dates being considered not-equal is<br>
> as jarring as your counter example of two non-equal dates (different<br>
> timezone) being considered equal.<br>
<br>
There doesn't seem to be an easy, direct solution because I'm assuming we<br>
don't have a primitive for "the offset at this location on X date in the<br>
past". So the next best thing might be a PlatonicDate (obviously a<br>
name-in-progress :)) that represents the abstract idea of a Date without<br>
regard to location, and then an object to connect a particular place/offset<br>
to that concept (but the second one would have the same problem as we<br>
currently have).<br>
<br>
<br></blockquote><div><br><div>Of course, a PlatonicDate would be so much simpler...<br></div><div>It's a different thing though.<br></div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-----<br>
Cheers,<br>
Sean<br>
--<br>
View this message in context: <a href="http://forum.world.st/What-s-up-on-build-squeak-org-tp4760266p4774978.html" target="_blank">http://forum.world.st/What-s-up-on-build-squeak-org-tp4760266p4774978.html</a><br>
Sent from the Squeak - Dev mailing list archive at Nabble.com.<br>
<br>
</blockquote></div><br></div></div>