<div dir="ltr"><div dir="ltr">Hi all,<br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 19, 2018 at 7:15 PM H. Hirzel <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">+1 for 5.2.1<br>
<br>
On 10/19/18, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br>
> Do you mean 5.2.1? If not, then no, we just cannot call a different image<br>
> 5.2.<br>
><br>
> Levente<br>
><br>
> On Fri, 19 Oct 2018, Chris Muller wrote:<br>
><br>
>> Oh my, I didn't know we had that bug too! Yes, we will definitely<br>
>> want to include that, too, since people might want to be able to join<br>
>> trunk development!<br>
>><br>
>> We could either freshen the images or just hope the user clicks on<br>
>> "Update Squeak". Personally, I think we should put out a new set of<br>
>> images, but I don't know how to do that myself. Fabio is that you?<br>
>> Would you be willing to push them one more time?<br></blockquote><div><br></div><div>Sure, we could do another release in the next few days, but I would</div><div>probably rename the current one to 5.2a on the website and call</div><div>the new one 5.2b instead of 5.2.1 (just like 4.5a and 4.5b). Both would</div><div>live as 5.2 bundles at [1] but with different update levels.</div><div><br></div><div>Thoughts? When shall we do this? This Sunday maybe?</div><div><br></div><div>Fabio</div><div><br></div><div>[1] <a href="http://files.squeak.org/5.2/">http://files.squeak.org/5.2/</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>><br>
>> Bert, are you going to be okay with this fix at least for now? Chris<br>
>> Cunningham's explanation of why updating #hash to not account for<br>
>> offset was an excellent analysis of why it may not be the best idea.<br>
>> We should just go back to hard types for now. I will add one more set<br>
>> of convenience methods to Timespan make this even easier and<br>
>> more-explicit... (e,g,, #asDatespan ^ self asDate).<br>
>><br>
>> - Chris<br>
>> On Fri, Oct 19, 2018 at 8:56 AM Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi Chris,<br>
>>><br>
>>> > On Oct 18, 2018, at 7:10 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
>>> ><br>
>>> > It's a really bad bug, we should backport the fix to the new 5.2<br>
>>> > release ASAP hopefully before the News announcement.<br>
>>><br>
>>> If we’re going to “freshen” the 5.2 release we should do it quickly and<br>
>>> be sure to include my fix to preferences that allows one to change the<br>
>>> update URL.<br>
>>><br>
>>> ><br>
>>> > In the meantime, a fix is available by loading<br>
>>> > Chronology-Core-cmm.15.mcz from the Inbox. With that you can do<br>
>>> > everything. No limitations, just be sure when you use #asDate on a<br>
>>> > DateAndTime, since its a date that originated from a<br>
>>> > timezone-sensitive object, it retains that timezone, so if you want to<br>
>>> > use it in a system of canonical dates, you need to convert it by<br>
>>> > sending either #beCanonical or #stripTimezone (whichever you prefer),<br>
>>> > then it will compare equally with the one from "Date today" (which<br>
>>> > always produces a canonical date).<br>
>>> ><br>
>>> > - Chris<br>
>>> >> On Thu, Oct 18, 2018 at 8:04 PM Tim Johnson <<a href="mailto:digit@sonic.net" target="_blank">digit@sonic.net</a>> wrote:<br>
>>> >><br>
>>> >> Hi,<br>
>>> >><br>
>>> >> I am very grateful to see the discussions about timezones on the list<br>
>>> >> recently, because I just got hit by it today.<br>
>>> >><br>
>>> >> I couldn't figure out why a Set containing Date objects didn't<br>
>>> >> properly<br>
>>> >> detect membership of a Date which was clearly present in the Set. It<br>
>>> >> was<br>
>>> >> because, I realize now, the Date objects in the Set had an offset of<br>
>>> >> -0:07:00:00 (they are created by DateAndTime>>#now), and Dates<br>
>>> >> created<br>
>>> >> by e.g. "Date today" or "Date yesterday" either have no offset or the<br>
>>> >> offset is 0:00:00:00. I have found the comment in Timespan<br>
>>> >> class>>#defaultOffset -- but it does not encourage me that I could<br>
>>> >> change my defaultOffset to help myself.<br>
>>> >><br>
>>> >> In my tests (code snippet below), if I make an OrderedCollection from<br>
>>> >> the Set, the OrderedCollection can find the date object, even though<br>
>>> >> the<br>
>>> >> Set can't.<br>
>>> >><br>
>>> >> In the Mean Time (get it?), can I create Dates with offsets?<br>
>>> >> "(DateAndTime now - 1 day) asDate" works...? Or are there any other<br>
>>> >> workarounds? Should I walk away from Date and use something else?<br>
>>> >><br>
>>> >> Thanks!<br>
>>> >><br>
>>> >> (in a Workspace)<br>
>>> >> | dates |<br>
>>> >> dates := Set newFrom: { Date yesterday. Date tomorrow. DateAndTime<br>
>>> >> now<br>
>>> >> asDate }.<br>
>>> >> dates includes: (Date year: 2018 month: 10 day: 18). "=> false"<br>
>>> >> dates asOrderedCollection includes: (Date year: 2018 month: 10 day:<br>
>>> >> 18).<br>
>>> >> "=> true"<br>
>>> >><br>
>>> >><br>
>>> >> (in an inspector on a Set of dates with offsets)<br>
>>> >> | a m |<br>
>>> >> a := Date year: 2018 month: 10 day: 17.<br>
>>> >> self includes: a. "-> false"<br>
>>> >> self like: a. "-> nil"<br>
>>> >> self asOrderedCollection includes: a. "-> true"<br>
>>> >> m := self array at: 4. "-> 17 October 2018"<br>
>>> >> m start offset. "-> -0:07:00:00"<br>
>>> >> a start offset "-> 0:00:00:00"<br>
>>> >><br>
>>> >><br>
>>> ><br>
>>><br>
<br>
</blockquote></div></div></div>