Testing membership in a Set of Date objects
Locked
Testing membership in a Set of Date objects
 
|
Hi,
I am very grateful to see the discussions about timezones on the list recently, because I just got hit by it today. I couldn't figure out why a Set containing Date objects didn't properly detect membership of a Date which was clearly present in the Set. It was because, I realize now, the Date objects in the Set had an offset of -0:07:00:00 (they are created by DateAndTime>>#now), and Dates created by e.g. "Date today" or "Date yesterday" either have no offset or the offset is 0:00:00:00. I have found the comment in Timespan class>>#defaultOffset -- but it does not encourage me that I could change my defaultOffset to help myself. In my tests (code snippet below), if I make an OrderedCollection from the Set, the OrderedCollection can find the date object, even though the Set can't. In the Mean Time (get it?), can I create Dates with offsets? "(DateAndTime now - 1 day) asDate" works...? Or are there any other workarounds? Should I walk away from Date and use something else? Thanks! (in a Workspace) | dates | dates := Set newFrom: { Date yesterday. Date tomorrow. DateAndTime now asDate }. dates includes: (Date year: 2018 month: 10 day: 18). "=> false" dates asOrderedCollection includes: (Date year: 2018 month: 10 day: 18). "=> true" (in an inspector on a Set of dates with offsets) | a m | a := Date year: 2018 month: 10 day: 17. self includes: a. "-> false" self like: a. "-> nil" self asOrderedCollection includes: a. "-> true" m := self array at: 4. "-> 17 October 2018" m start offset. "-> -0:07:00:00" a start offset "-> 0:00:00:00" |
Re: Testing membership in a Set of Date objects
|
|
It's a really bad bug, we should backport the fix to the new 5.2
release ASAP hopefully before the News announcement. In the meantime, a fix is available by loading Chronology-Core-cmm.15.mcz from the Inbox. With that you can do everything. No limitations, just be sure when you use #asDate on a DateAndTime, since its a date that originated from a timezone-sensitive object, it retains that timezone, so if you want to use it in a system of canonical dates, you need to convert it by sending either #beCanonical or #stripTimezone (whichever you prefer), then it will compare equally with the one from "Date today" (which always produces a canonical date). - Chris On Thu, Oct 18, 2018 at 8:04 PM Tim Johnson <[hidden email]> wrote: > > Hi, > > I am very grateful to see the discussions about timezones on the list > recently, because I just got hit by it today. > > I couldn't figure out why a Set containing Date objects didn't properly > detect membership of a Date which was clearly present in the Set. It was > because, I realize now, the Date objects in the Set had an offset of > -0:07:00:00 (they are created by DateAndTime>>#now), and Dates created > by e.g. "Date today" or "Date yesterday" either have no offset or the > offset is 0:00:00:00. I have found the comment in Timespan > class>>#defaultOffset -- but it does not encourage me that I could > change my defaultOffset to help myself. > > In my tests (code snippet below), if I make an OrderedCollection from > the Set, the OrderedCollection can find the date object, even though the > Set can't. > > In the Mean Time (get it?), can I create Dates with offsets? > "(DateAndTime now - 1 day) asDate" works...? Or are there any other > workarounds? Should I walk away from Date and use something else? > > Thanks! > > (in a Workspace) > | dates | > dates := Set newFrom: { Date yesterday. Date tomorrow. DateAndTime now > asDate }. > dates includes: (Date year: 2018 month: 10 day: 18). "=> false" > dates asOrderedCollection includes: (Date year: 2018 month: 10 day: 18). > "=> true" > > > (in an inspector on a Set of dates with offsets) > | a m | > a := Date year: 2018 month: 10 day: 17. > self includes: a. "-> false" > self like: a. "-> nil" > self asOrderedCollection includes: a. "-> true" > m := self array at: 4. "-> 17 October 2018" > m start offset. "-> -0:07:00:00" > a start offset "-> 0:00:00:00" > > |
Re: Testing membership in a Set of Date objects
|
|
Hi Chris,
> On Oct 18, 2018, at 7:10 PM, Chris Muller <[hidden email]> wrote: > > It's a really bad bug, we should backport the fix to the new 5.2 > release ASAP hopefully before the News announcement. If we’re going to “freshen” the 5.2 release we should do it quickly and be sure to include my fix to preferences that allows one to change the update URL. > > In the meantime, a fix is available by loading > Chronology-Core-cmm.15.mcz from the Inbox. With that you can do > everything. No limitations, just be sure when you use #asDate on a > DateAndTime, since its a date that originated from a > timezone-sensitive object, it retains that timezone, so if you want to > use it in a system of canonical dates, you need to convert it by > sending either #beCanonical or #stripTimezone (whichever you prefer), > then it will compare equally with the one from "Date today" (which > always produces a canonical date). > > - Chris >> On Thu, Oct 18, 2018 at 8:04 PM Tim Johnson <[hidden email]> wrote: >> >> Hi, >> >> I am very grateful to see the discussions about timezones on the list >> recently, because I just got hit by it today. >> >> I couldn't figure out why a Set containing Date objects didn't properly >> detect membership of a Date which was clearly present in the Set. It was >> because, I realize now, the Date objects in the Set had an offset of >> -0:07:00:00 (they are created by DateAndTime>>#now), and Dates created >> by e.g. "Date today" or "Date yesterday" either have no offset or the >> offset is 0:00:00:00. I have found the comment in Timespan >> class>>#defaultOffset -- but it does not encourage me that I could >> change my defaultOffset to help myself. >> >> In my tests (code snippet below), if I make an OrderedCollection from >> the Set, the OrderedCollection can find the date object, even though the >> Set can't. >> >> In the Mean Time (get it?), can I create Dates with offsets? >> "(DateAndTime now - 1 day) asDate" works...? Or are there any other >> workarounds? Should I walk away from Date and use something else? >> >> Thanks! >> >> (in a Workspace) >> | dates | >> dates := Set newFrom: { Date yesterday. Date tomorrow. DateAndTime now >> asDate }. >> dates includes: (Date year: 2018 month: 10 day: 18). "=> false" >> dates asOrderedCollection includes: (Date year: 2018 month: 10 day: 18). >> "=> true" >> >> >> (in an inspector on a Set of dates with offsets) >> | a m | >> a := Date year: 2018 month: 10 day: 17. >> self includes: a. "-> false" >> self like: a. "-> nil" >> self asOrderedCollection includes: a. "-> true" >> m := self array at: 4. "-> 17 October 2018" >> m start offset. "-> -0:07:00:00" >> a start offset "-> 0:00:00:00" >> >> > |
Re: Testing membership in a Set of Date objects
|
|
Oh my, I didn't know we had that bug too! Yes, we will definitely
want to include that, too, since people might want to be able to join trunk development! We could either freshen the images or just hope the user clicks on "Update Squeak". Personally, I think we should put out a new set of images, but I don't know how to do that myself. Fabio is that you? Would you be willing to push them one more time? Bert, are you going to be okay with this fix at least for now? Chris Cunningham's explanation of why updating #hash to not account for offset was an excellent analysis of why it may not be the best idea. We should just go back to hard types for now. I will add one more set of convenience methods to Timespan make this even easier and more-explicit... (e,g,, #asDatespan ^ self asDate). - Chris On Fri, Oct 19, 2018 at 8:56 AM Eliot Miranda <[hidden email]> wrote: > > Hi Chris, > > > On Oct 18, 2018, at 7:10 PM, Chris Muller <[hidden email]> wrote: > > > > It's a really bad bug, we should backport the fix to the new 5.2 > > release ASAP hopefully before the News announcement. > > If we’re going to “freshen” the 5.2 release we should do it quickly and be sure to include my fix to preferences that allows one to change the update URL. > > > > > In the meantime, a fix is available by loading > > Chronology-Core-cmm.15.mcz from the Inbox. With that you can do > > everything. No limitations, just be sure when you use #asDate on a > > DateAndTime, since its a date that originated from a > > timezone-sensitive object, it retains that timezone, so if you want to > > use it in a system of canonical dates, you need to convert it by > > sending either #beCanonical or #stripTimezone (whichever you prefer), > > then it will compare equally with the one from "Date today" (which > > always produces a canonical date). > > > > - Chris > >> On Thu, Oct 18, 2018 at 8:04 PM Tim Johnson <[hidden email]> wrote: > >> > >> Hi, > >> > >> I am very grateful to see the discussions about timezones on the list > >> recently, because I just got hit by it today. > >> > >> I couldn't figure out why a Set containing Date objects didn't properly > >> detect membership of a Date which was clearly present in the Set. It was > >> because, I realize now, the Date objects in the Set had an offset of > >> -0:07:00:00 (they are created by DateAndTime>>#now), and Dates created > >> by e.g. "Date today" or "Date yesterday" either have no offset or the > >> offset is 0:00:00:00. I have found the comment in Timespan > >> class>>#defaultOffset -- but it does not encourage me that I could > >> change my defaultOffset to help myself. > >> > >> In my tests (code snippet below), if I make an OrderedCollection from > >> the Set, the OrderedCollection can find the date object, even though the > >> Set can't. > >> > >> In the Mean Time (get it?), can I create Dates with offsets? > >> "(DateAndTime now - 1 day) asDate" works...? Or are there any other > >> workarounds? Should I walk away from Date and use something else? > >> > >> Thanks! > >> > >> (in a Workspace) > >> | dates | > >> dates := Set newFrom: { Date yesterday. Date tomorrow. DateAndTime now > >> asDate }. > >> dates includes: (Date year: 2018 month: 10 day: 18). "=> false" > >> dates asOrderedCollection includes: (Date year: 2018 month: 10 day: 18). > >> "=> true" > >> > >> > >> (in an inspector on a Set of dates with offsets) > >> | a m | > >> a := Date year: 2018 month: 10 day: 17. > >> self includes: a. "-> false" > >> self like: a. "-> nil" > >> self asOrderedCollection includes: a. "-> true" > >> m := self array at: 4. "-> 17 October 2018" > >> m start offset. "-> -0:07:00:00" > >> a start offset "-> 0:00:00:00" > >> > >> > > > |
Re: Testing membership in a Set of Date objects
|
|
Do you mean 5.2.1? If not, then no, we just cannot call a different image
5.2. Levente On Fri, 19 Oct 2018, Chris Muller wrote: > Oh my, I didn't know we had that bug too! Yes, we will definitely > want to include that, too, since people might want to be able to join > trunk development! > > We could either freshen the images or just hope the user clicks on > "Update Squeak". Personally, I think we should put out a new set of > images, but I don't know how to do that myself. Fabio is that you? > Would you be willing to push them one more time? > > Bert, are you going to be okay with this fix at least for now? Chris > Cunningham's explanation of why updating #hash to not account for > offset was an excellent analysis of why it may not be the best idea. > We should just go back to hard types for now. I will add one more set > of convenience methods to Timespan make this even easier and > more-explicit... (e,g,, #asDatespan ^ self asDate). > > - Chris > On Fri, Oct 19, 2018 at 8:56 AM Eliot Miranda <[hidden email]> wrote: >> >> Hi Chris, >> >> > On Oct 18, 2018, at 7:10 PM, Chris Muller <[hidden email]> wrote: >> > >> > It's a really bad bug, we should backport the fix to the new 5.2 >> > release ASAP hopefully before the News announcement. >> >> If we’re going to “freshen” the 5.2 release we should do it quickly and be sure to include my fix to preferences that allows one to change the update URL. >> >> > >> > In the meantime, a fix is available by loading >> > Chronology-Core-cmm.15.mcz from the Inbox. With that you can do >> > everything. No limitations, just be sure when you use #asDate on a >> > DateAndTime, since its a date that originated from a >> > timezone-sensitive object, it retains that timezone, so if you want to >> > use it in a system of canonical dates, you need to convert it by >> > sending either #beCanonical or #stripTimezone (whichever you prefer), >> > then it will compare equally with the one from "Date today" (which >> > always produces a canonical date). >> > >> > - Chris >> >> On Thu, Oct 18, 2018 at 8:04 PM Tim Johnson <[hidden email]> wrote: >> >> >> >> Hi, >> >> >> >> I am very grateful to see the discussions about timezones on the list >> >> recently, because I just got hit by it today. >> >> >> >> I couldn't figure out why a Set containing Date objects didn't properly >> >> detect membership of a Date which was clearly present in the Set. It was >> >> because, I realize now, the Date objects in the Set had an offset of >> >> -0:07:00:00 (they are created by DateAndTime>>#now), and Dates created >> >> by e.g. "Date today" or "Date yesterday" either have no offset or the >> >> offset is 0:00:00:00. I have found the comment in Timespan >> >> class>>#defaultOffset -- but it does not encourage me that I could >> >> change my defaultOffset to help myself. >> >> >> >> In my tests (code snippet below), if I make an OrderedCollection from >> >> the Set, the OrderedCollection can find the date object, even though the >> >> Set can't. >> >> >> >> In the Mean Time (get it?), can I create Dates with offsets? >> >> "(DateAndTime now - 1 day) asDate" works...? Or are there any other >> >> workarounds? Should I walk away from Date and use something else? >> >> >> >> Thanks! >> >> >> >> (in a Workspace) >> >> | dates | >> >> dates := Set newFrom: { Date yesterday. Date tomorrow. DateAndTime now >> >> asDate }. >> >> dates includes: (Date year: 2018 month: 10 day: 18). "=> false" >> >> dates asOrderedCollection includes: (Date year: 2018 month: 10 day: 18). >> >> "=> true" >> >> >> >> >> >> (in an inspector on a Set of dates with offsets) >> >> | a m | >> >> a := Date year: 2018 month: 10 day: 17. >> >> self includes: a. "-> false" >> >> self like: a. "-> nil" >> >> self asOrderedCollection includes: a. "-> true" >> >> m := self array at: 4. "-> 17 October 2018" >> >> m start offset. "-> -0:07:00:00" >> >> a start offset "-> 0:00:00:00" >> >> >> >> >> > >> |
Re: Testing membership in a Set of Date objects
|
|
+1 for 5.2.1
On 10/19/18, Levente Uzonyi <[hidden email]> wrote: > Do you mean 5.2.1? If not, then no, we just cannot call a different image > 5.2. > > Levente > > On Fri, 19 Oct 2018, Chris Muller wrote: > >> Oh my, I didn't know we had that bug too! Yes, we will definitely >> want to include that, too, since people might want to be able to join >> trunk development! >> >> We could either freshen the images or just hope the user clicks on >> "Update Squeak". Personally, I think we should put out a new set of >> images, but I don't know how to do that myself. Fabio is that you? >> Would you be willing to push them one more time? >> >> Bert, are you going to be okay with this fix at least for now? Chris >> Cunningham's explanation of why updating #hash to not account for >> offset was an excellent analysis of why it may not be the best idea. >> We should just go back to hard types for now. I will add one more set >> of convenience methods to Timespan make this even easier and >> more-explicit... (e,g,, #asDatespan ^ self asDate). >> >> - Chris >> On Fri, Oct 19, 2018 at 8:56 AM Eliot Miranda <[hidden email]> >> wrote: >>> >>> Hi Chris, >>> >>> > On Oct 18, 2018, at 7:10 PM, Chris Muller <[hidden email]> wrote: >>> > >>> > It's a really bad bug, we should backport the fix to the new 5.2 >>> > release ASAP hopefully before the News announcement. >>> >>> If we’re going to “freshen” the 5.2 release we should do it quickly and >>> be sure to include my fix to preferences that allows one to change the >>> update URL. >>> >>> > >>> > In the meantime, a fix is available by loading >>> > Chronology-Core-cmm.15.mcz from the Inbox. With that you can do >>> > everything. No limitations, just be sure when you use #asDate on a >>> > DateAndTime, since its a date that originated from a >>> > timezone-sensitive object, it retains that timezone, so if you want to >>> > use it in a system of canonical dates, you need to convert it by >>> > sending either #beCanonical or #stripTimezone (whichever you prefer), >>> > then it will compare equally with the one from "Date today" (which >>> > always produces a canonical date). >>> > >>> > - Chris >>> >> On Thu, Oct 18, 2018 at 8:04 PM Tim Johnson <[hidden email]> wrote: >>> >> >>> >> Hi, >>> >> >>> >> I am very grateful to see the discussions about timezones on the list >>> >> recently, because I just got hit by it today. >>> >> >>> >> I couldn't figure out why a Set containing Date objects didn't >>> >> properly >>> >> detect membership of a Date which was clearly present in the Set. It >>> >> was >>> >> because, I realize now, the Date objects in the Set had an offset of >>> >> -0:07:00:00 (they are created by DateAndTime>>#now), and Dates >>> >> created >>> >> by e.g. "Date today" or "Date yesterday" either have no offset or the >>> >> offset is 0:00:00:00. I have found the comment in Timespan >>> >> class>>#defaultOffset -- but it does not encourage me that I could >>> >> change my defaultOffset to help myself. >>> >> >>> >> In my tests (code snippet below), if I make an OrderedCollection from >>> >> the Set, the OrderedCollection can find the date object, even though >>> >> the >>> >> Set can't. >>> >> >>> >> In the Mean Time (get it?), can I create Dates with offsets? >>> >> "(DateAndTime now - 1 day) asDate" works...? Or are there any other >>> >> workarounds? Should I walk away from Date and use something else? >>> >> >>> >> Thanks! >>> >> >>> >> (in a Workspace) >>> >> | dates | >>> >> dates := Set newFrom: { Date yesterday. Date tomorrow. DateAndTime >>> >> now >>> >> asDate }. >>> >> dates includes: (Date year: 2018 month: 10 day: 18). "=> false" >>> >> dates asOrderedCollection includes: (Date year: 2018 month: 10 day: >>> >> 18). >>> >> "=> true" >>> >> >>> >> >>> >> (in an inspector on a Set of dates with offsets) >>> >> | a m | >>> >> a := Date year: 2018 month: 10 day: 17. >>> >> self includes: a. "-> false" >>> >> self like: a. "-> nil" >>> >> self asOrderedCollection includes: a. "-> true" >>> >> m := self array at: 4. "-> 17 October 2018" >>> >> m start offset. "-> -0:07:00:00" >>> >> a start offset "-> 0:00:00:00" >>> >> >>> >> >>> > >>> |
|
|
In reply to this post by Tim Johnson-2
Hi Tim, On Thu, Oct 18, 2018 at 6:04 PM Tim Johnson <[hidden email]> wrote: Hi, If you load the latest proposed fix that we are talking about (Chronology-Core-cmm.15.mcz from the inbox), the results do change: (in a Workspace) | dates | dates := Set newFrom: { Date yesterday. Date tomorrow. DateAndTime now asDate }. dates includes: (Date year: 2018 month: 10 day: 19). "=> false" "=> false" dates asOrderedCollection includes: (Date year: 2018 month: 10 day: 19). "=> true" "=> false" (first results pre-load, second results post-load). (changed your example for today - otherwise you get true for both questions) This change doesn't fix what you are getting - but at least the results are consistent. The issue is that a generic time-zone-less date is not the same thing as a date with a specific timezone. The current code mostly made this true (as shown in the OrderedCollection test) but not fully (as shown in your Set test). As Chris Muller pointed out, if you send #stripTimezone with the new fix to your array of dates before putting them into the set, I think you will get what you want: (in a Workspace) | dates | dates := Set newFrom: ( { Date yesterday. Date tomorrow. DateAndTime now asDate } collect: #stripTimezone ). dates includes: (Date year: 2018 month: 10 day: 19). "true" dates asOrderedCollection includes: (Date year: 2018 month: 10 day: 19). "true" Would it be convenient for you to try out the proposed Chronology fix in your case (with or without the #stripTimezone), and report back if this works well for you? I'd like to make dates work like we all think they should. -cbc
|
Re: Testing membership in a Set of Date objects
|
|
In reply to this post by Levente Uzonyi
5.2.1 is fine. Given that 5.2 has not even been announced outside of
this list yet, it may not matter much except to the person who has to update the download links... On Fri, Oct 19, 2018 at 12:07 PM Levente Uzonyi <[hidden email]> wrote: > > Do you mean 5.2.1? If not, then no, we just cannot call a different image > 5.2. > > Levente > > On Fri, 19 Oct 2018, Chris Muller wrote: > > > Oh my, I didn't know we had that bug too! Yes, we will definitely > > want to include that, too, since people might want to be able to join > > trunk development! > > > > We could either freshen the images or just hope the user clicks on > > "Update Squeak". Personally, I think we should put out a new set of > > images, but I don't know how to do that myself. Fabio is that you? > > Would you be willing to push them one more time? > > > > Bert, are you going to be okay with this fix at least for now? Chris > > Cunningham's explanation of why updating #hash to not account for > > offset was an excellent analysis of why it may not be the best idea. > > We should just go back to hard types for now. I will add one more set > > of convenience methods to Timespan make this even easier and > > more-explicit... (e,g,, #asDatespan ^ self asDate). > > > > - Chris > > On Fri, Oct 19, 2018 at 8:56 AM Eliot Miranda <[hidden email]> wrote: > >> > >> Hi Chris, > >> > >> > On Oct 18, 2018, at 7:10 PM, Chris Muller <[hidden email]> wrote: > >> > > >> > It's a really bad bug, we should backport the fix to the new 5.2 > >> > release ASAP hopefully before the News announcement. > >> > >> If we’re going to “freshen” the 5.2 release we should do it quickly and be sure to include my fix to preferences that allows one to change the update URL. > >> > >> > > >> > In the meantime, a fix is available by loading > >> > Chronology-Core-cmm.15.mcz from the Inbox. With that you can do > >> > everything. No limitations, just be sure when you use #asDate on a > >> > DateAndTime, since its a date that originated from a > >> > timezone-sensitive object, it retains that timezone, so if you want to > >> > use it in a system of canonical dates, you need to convert it by > >> > sending either #beCanonical or #stripTimezone (whichever you prefer), > >> > then it will compare equally with the one from "Date today" (which > >> > always produces a canonical date). > >> > > >> > - Chris > >> >> On Thu, Oct 18, 2018 at 8:04 PM Tim Johnson <[hidden email]> wrote: > >> >> > >> >> Hi, > >> >> > >> >> I am very grateful to see the discussions about timezones on the list > >> >> recently, because I just got hit by it today. > >> >> > >> >> I couldn't figure out why a Set containing Date objects didn't properly > >> >> detect membership of a Date which was clearly present in the Set. It was > >> >> because, I realize now, the Date objects in the Set had an offset of > >> >> -0:07:00:00 (they are created by DateAndTime>>#now), and Dates created > >> >> by e.g. "Date today" or "Date yesterday" either have no offset or the > >> >> offset is 0:00:00:00. I have found the comment in Timespan > >> >> class>>#defaultOffset -- but it does not encourage me that I could > >> >> change my defaultOffset to help myself. > >> >> > >> >> In my tests (code snippet below), if I make an OrderedCollection from > >> >> the Set, the OrderedCollection can find the date object, even though the > >> >> Set can't. > >> >> > >> >> In the Mean Time (get it?), can I create Dates with offsets? > >> >> "(DateAndTime now - 1 day) asDate" works...? Or are there any other > >> >> workarounds? Should I walk away from Date and use something else? > >> >> > >> >> Thanks! > >> >> > >> >> (in a Workspace) > >> >> | dates | > >> >> dates := Set newFrom: { Date yesterday. Date tomorrow. DateAndTime now > >> >> asDate }. > >> >> dates includes: (Date year: 2018 month: 10 day: 18). "=> false" > >> >> dates asOrderedCollection includes: (Date year: 2018 month: 10 day: 18). > >> >> "=> true" > >> >> > >> >> > >> >> (in an inspector on a Set of dates with offsets) > >> >> | a m | > >> >> a := Date year: 2018 month: 10 day: 17. > >> >> self includes: a. "-> false" > >> >> self like: a. "-> nil" > >> >> self asOrderedCollection includes: a. "-> true" > >> >> m := self array at: 4. "-> 17 October 2018" > >> >> m start offset. "-> -0:07:00:00" > >> >> a start offset "-> 0:00:00:00" > >> >> > >> >> > >> > > >> |
|
In reply to this post by Hannes Hirzel
Hi all, On Fri, Oct 19, 2018 at 7:15 PM H. Hirzel <[hidden email]> wrote: +1 for 5.2.1 Sure, we could do another release in the next few days, but I would probably rename the current one to 5.2a on the website and call the new one 5.2b instead of 5.2.1 (just like 4.5a and 4.5b). Both would live as 5.2 bundles at [1] but with different update levels. Thoughts? When shall we do this? This Sunday maybe? Fabio >> |
Re: Testing membership in a Set of Date objects
|
|
Hi Fabio, Hi All, On Fri, Oct 19, 2018 at 11:09 AM Fabio Niephaus <[hidden email]> wrote:
+1000
Sounds good to me. I'd also like to see the latest VM included (the one I committed yesterday that passed all build tests, VMMaker.oscog-eem.2464) because it fixes a serious bug in BitBlt that can crash the system when using external forms. It is not essential, so if this doesn't feel right to you, keep the existing VMs (VMMaker.oscog-eem.2437). But the fix is goodness and there are no other significant changes other than a fix to primitiveAdoptInstance, so no chance of regression. Most of the changes between 2437 and 2464 are either refactoring to allow VMMaker to function in Pharo, or work on SpurSelectiveCompactor by Clément which is experimental and doesn't affect the generated source. Another change is merely as refactoring of the vmParameterAt:put: primitives into separate methods.
_,,,^..^,,,_ best, Eliot |
Re: Testing membership in a Set of Date objects
|
|
In reply to this post by cbc
Hi Chris, Thanks to you and Chris M. and company. I was excited to try this out today but got sucked into a spinning vortex of unexpected messes. It seemed in a separate thread that folks might be leaning toward crafting a different solution at the moment...? In any case, my project makes heavy use of Timespan, DateAndTime, and Date, so I believe it will be a good test subject. My working image stayed at work so I won't be returning to it until Monday, and it held abundant data to test with. But I did push my project up to GitHub, and as such could try it out over the weekend – I'll just be missing all the data. Best, Tim |
Re: Testing membership in a Set of Date objects
|
|
Hi Tim,
On Fri, Oct 19, 2018 at 06:13:10PM -0700, Tim Johnson wrote: > > > > On Oct 19, 2018, at 10:52 AM, Chris Cunningham <[hidden email]> wrote: > > > > (in a Workspace) > > | dates | > > dates := Set newFrom: ( { Date yesterday. Date tomorrow. DateAndTime now asDate } collect: #stripTimezone ). > > dates includes: (Date year: 2018 month: 10 day: 19). "true" > > dates asOrderedCollection includes: (Date year: 2018 month: 10 day: 19). "true" > > > > Would it be convenient for you to try out the proposed Chronology fix in your case (with or without the #stripTimezone), and report back if this works well for you? I'd like to make dates work like we all think they should. > > Hi Chris, > > Thanks to you and Chris M. and company. I was excited to try this out today but got sucked into a spinning vortex of unexpected messes. > > It seemed in a separate thread that folks might be leaning toward crafting a different solution at the moment...? > > In any case, my project makes heavy use of Timespan, DateAndTime, and Date, so I believe it will be a good test subject. My working image stayed at work so I won't be returning to it until Monday, and it held abundant data to test with. But I did push my project up to GitHub, and as such could try it out over the weekend ??? I'll just be missing all the data. > Yes you're right, there are two different threads. This one is about fixing an an important issue in the current Squeak 5.2 release. The other discussion concerns UTCDateAndTime: http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-October/200322.html This is something we are considering bringing into trunk for Squeak 5.3 and beyond. It's a big enough change that it would be good to bring it in early in the release cycle, hence the discussion now. If you could try UTCDateAndTime with your project and see if it causes any issues for you, that would be a huge help. You can install UTCDateAndTime into a Squeak 5.2 image from the SqueakMap loader. Please be sure to use a copy of your image when you do this, because the changes are easy to install but nearly impossible to remove. Thanks in advance, I would really appreciate getting some real-world feedback on this :-) Dave |
Re: Testing membership in a Set of Date objects
|
|
In reply to this post by Chris Muller-3
Thanks. I have had a chance to test this now. After loading Chronology-Core-cmm.15.mcz, a couple of my tests failed, as could be expected. By adapting my method: timespan ^ Timespan starting: (oldRecord timestamp) ending: (newRecord timestamp) (considering the timestamps originate from DateAndTime class>>#now) to: timespan ^ (Timespan starting: (oldRecord timestamp) ending: (newRecord timestamp)) beCanonical all my tests pass. Great! My code relies on Timespan>>#dates. So, this is one test which failed with Chronology-Core-cmm.15.mcz until I made the change above: self assert: (span2 dates includes: (Date year: 2018 month: 8 day: 16)). (I was puzzled for a minute how my code would handle that #beCanonical and #stripTimezone modify objects in-place rather than returning modified copies... but as soon as I realized I could just make the above change, the clouds went away and life became beautiful.) Thanks again, Tim tcj |
Re: Testing membership in a Set of Date objects
|
|
Sadly, this turned out to be less of a miracle than I'd originally thought. The Timespan class>#starting:ending: constructor retains the DateAndTime object given to #starting: . So, when I later called #beCanonical on the Timespans I created (from the code above), I was unintentionally changing each of my "oldRecord" (see above) timestamps to be offset: nil. Whoops. Now I have thousands of these objects whose oldRecord timestamp is offset = nil and whose newRecord timestamp offset is still -07:00, causing all of my calculations to be off by 7 hours. Time to revert to my previously-saved data, and find another solution/adaptation. :) Thanks, Tim |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |