> Chris, makeUTC already solved your both problems right?
> - it makes Date comparable, even when coming from DateAndTime of > different time zone > - it makes hash fast enough Thanks Nicolas. I actually have 37 senders of it in my financial app which has become intolerable. So I think makeUTC started out as a quick-fix to address those issues and get me by until I could think more about it. Now I believe I have a good solution in the Inbox. > I also notice that the offset used to create a DateAndTime is NOT > taken into account when extracting the Date... > The Date is always extracted with local time zone which is ... weird. Agreed. So international-systems that need Timezone-sensitive Dates are all mixed up -- because it wants to always create them in the local-offset of the running computer regardless of the timezone of the source data. I've changed that. Now, Timespan offsets are cascaded forward from their source -- whether that source be a DateAndTime, another Timespan, or a user-specification (e.g., method argument). When the offset is not specified, it will look to a new class-instance variable: 'defaultOffset'. The default value for defaultOffset must be Duration zero not just for optimal hashing, but also so that more unsuspecting Squeakers besides me and Jon don't get bitten so badly. In my case, offset differences in Date objects resulted in arithmetic testing to choose the wrong logic paths. There was no blow up, just corrupt data. Ouch! The legacy behavior, Dates that start at midnight of the local-offset can be gotten by simply updating the defaultOffset thusly: Date localize All tests pass except maybe not Timespan since its going to be purged. I'm going to chew on it for at least week -- if anyone wants to test their app that'd be good too. |
On Fri, Feb 03, 2012 at 06:35:02PM -0600, Chris Muller wrote:
> > Chris, makeUTC already solved your both problems right? > > - it makes Date comparable, even when coming from DateAndTime of > > different time zone > > - it makes hash fast enough > > Thanks Nicolas. I actually have 37 senders of it in my financial app > which has become intolerable. So I think makeUTC started out as a > quick-fix to address those issues and get me by until I could think > more about it. > > Now I believe I have a good solution in the Inbox. > > > I also notice that the offset used to create a DateAndTime is NOT > > taken into account when extracting the Date... > > The Date is always extracted with local time zone which is ... weird. > > Agreed. So international-systems that need Timezone-sensitive Dates > are all mixed up -- because it wants to always create them in the > local-offset of the running computer regardless of the timezone of the > source data. > > I've changed that. Now, Timespan offsets are cascaded forward from > their source -- whether that source be a DateAndTime, another > Timespan, or a user-specification (e.g., method argument). > > When the offset is not specified, it will look to a new class-instance > variable: 'defaultOffset'. > > The default value for defaultOffset must be Duration zero not just for > optimal hashing, but also so that more unsuspecting Squeakers besides > me and Jon don't get bitten so badly. In my case, offset differences > in Date objects resulted in arithmetic testing to choose the wrong > logic paths. There was no blow up, just corrupt data. Ouch! > > The legacy behavior, Dates that start at midnight of the local-offset > can be gotten by simply updating the defaultOffset thusly: > > Date localize > > All tests pass except maybe not Timespan since its going to be purged. > I'm going to chew on it for at least week -- if anyone wants to test > their app that'd be good too. I have not looked at this carefully, but after loading the update I get 27 failures and 7 errors running TimeTransformTest from TimeZoneDatabase, out of a total of 526 tests that should all pass. I'm struggling to understand why "Date today" should be a TimeSpan that begins at some time other than midnight in my local time zone. The date that I think of as "4 February 2012" began about 20 minutes ago here in Detroit, but in London and Paris it is old news. With the inbox update loaded, and using PointInTime to do the conversions: Date today start ==> 2012-02-04T00:00:00+00:00 Date today start asPointInTime asDateAndTime ==> 2012-02-03T19:00:00-05:00 This would mean that "Date today" began at 7:00pm yesterday, rather than at 12:00 midnight. I understand that this makes it easier to compare date objects, but ... Dave |
On Sat, Feb 4, 2012 at 12:43 AM, David T. Lewis <[hidden email]> wrote:
David, The issue that I'm having is this: When I evaluate and store this object today: (Date newDay: 1 month: 1 year: 2012), and then six months later I evaluate exactly the same expression, because I live in a country where daylight savings is applied, those two objects will not be equal.
I can't think of a single logical reason why it should work that way. When I create a date (any date), it sets the timezone of the date to be whatever current timezone I happen to be in. That makes Date completely unusable as a historical indexing object.
- Jon |
On Sat, Feb 04, 2012 at 11:57:51AM -0500, Jon Hylands wrote:
> On Sat, Feb 4, 2012 at 12:43 AM, David T. Lewis <[hidden email]> wrote: > > > > I'm struggling to understand why "Date today" should be a TimeSpan that > > begins at some time other than midnight in my local time zone. The date > > that I think of as "4 February 2012" began about 20 minutes ago here in > > Detroit, but in London and Paris it is old news. > > > > David, > > The issue that I'm having is this: > > When I evaluate and store this object today: (Date newDay: 1 month: 1 year: > 2012), and then six months later I evaluate exactly the same expression, > because I live in a country where daylight savings is applied, those two > objects will not be equal. Agreed. This is broken. DateAndTime is broken in exactly the same way. > > I can't think of a single logical reason why it should work that way. When > I create a date (any date), it sets the timezone of the date to be whatever > current timezone I happen to be in. That makes Date completely unusable as > a historical indexing object. Agreed. The "timezone" object is a trivial implementation that does not work when applied to periods of time like this. Dave |
In reply to this post by Jon Hylands
I would have proposed to create (Date newDay: 5 month: 2 year: 2012)
with a 0 offset because it has nothing to do with local time zone, unlike Date today... However, this might be a false good idea, because if we want this feature: (Date newDay: 5 month: 2 year: 2012) = Date today. then we need that both dates be in same time zone... There are several solutions possible then: 1) let the day start at local time zone, but use correct DST information at this date 2) erase offset information Unless we override Date>>=, but then Date wouldn't be a well behaved Timespan. So this leads to solution 3), create a new class unrelated to Timespan... Or solution 4) create explicit localized and unlocalized messages (or find better names)... For example Date today unlocalized Nicolas. 2012/2/4 Jon Hylands <[hidden email]>: > On Sat, Feb 4, 2012 at 12:43 AM, David T. Lewis <[hidden email]> wrote: > >> >> I'm struggling to understand why "Date today" should be a TimeSpan that >> begins at some time other than midnight in my local time zone. The date >> that I think of as "4 February 2012" began about 20 minutes ago here in >> Detroit, but in London and Paris it is old news. > > > David, > > The issue that I'm having is this: > > When I evaluate and store this object today: (Date newDay: 1 month: 1 year: > 2012), and then six months later I evaluate exactly the same expression, > because I live in a country where daylight savings is applied, those two > objects will not be equal. > > I can't think of a single logical reason why it should work that way. When I > create a date (any date), it sets the timezone of the date to be whatever > current timezone I happen to be in. That makes Date completely unusable as a > historical indexing object. > > - Jon > > > > |
In reply to this post by Jon Hylands
On Sat, Feb 04, 2012 at 11:57:51AM -0500, Jon Hylands wrote:
> On Sat, Feb 4, 2012 at 12:43 AM, David T. Lewis <[hidden email]> wrote: > > > > I'm struggling to understand why "Date today" should be a TimeSpan that > > begins at some time other than midnight in my local time zone. The date > > that I think of as "4 February 2012" began about 20 minutes ago here in > > Detroit, but in London and Paris it is old news. > > > > David, > > The issue that I'm having is this: > > When I evaluate and store this object today: (Date newDay: 1 month: 1 year: > 2012), and then six months later I evaluate exactly the same expression, > because I live in a country where daylight savings is applied, those two > objects will not be equal. > > I can't think of a single logical reason why it should work that way. When > I create a date (any date), it sets the timezone of the date to be whatever > current timezone I happen to be in. That makes Date completely unusable as > a historical indexing object. > > - Jon performance (Date>>hash) and time zone inconsistencies that Chris has been describing, it strikes me that a possible solution for those issues would be to have a type of date (call it "DateStamp") for which the equality test depends only the the julian date number associated with that date. The behavior would be like that of the old Date class that existed in Squeak prior to Chronology, where the hashing and comparison is based on a single SmallInteger value (julianDayNumber), hence fast and independent of time zone. Subclassing Date is not exactly elegant, but it's certainly simple and it might provide a practical way to address these problems without too many surprises for existing users of the Date class. I am not necessarily suggesting this for inclusion in the image, just offering it as a suggestion that might provide an easy way to address the performance and consistency issues. Change set attached. Dave DateStamp-dtl.1.cs (1K) Download Attachment |
In reply to this post by David T. Lewis
Hi Dave, thanks for the feedback. However, the yet-another-class
cannot actually satisfy my needs because I also require globalized Minute, Hour, Month, Quarter and Year timespans. I totally understand and appreciate what you are saying about having a "lean Date" a-la Squeak 3.6. Would you please look at the attached packages? This package goes back to 2004, prior to the existence of Chronology. It wraps a single LargeInteger to represent any point-in-time precise to the millisecond. In fact, observe version 44 of the package even went a step further and, rather than wrapping an Integer, it even *inherited* from Integer -- e.g., each MaDate WAS an Integer, with only behaviours. Guess what: It didn't perform any better than Chronology's 3 SmallIntegers. (The benchmark results are published in the version comments of the attached packages, check it out). Also, it created unnecessary converting complexities since there are other areas of the system that use the standard Chronology class. The other problem is: If we bring in yet-more-classes, where does that leave Date, et al? They're still horribly broken, as you said in your prior message. Unsuspecting Squeakers all over the world can be drastically affected by this. This is not just my problem, it's Squeak's problem, and it's a doozie -- wouldn't you say? The solution in the Inbox addresses all of the practical issues whilst retaining a single, consistent, coherent and correct implementation of time-objects for Squeak. It does not break Chronology. Dave, I've been deep down this road and have spent a LOT of time and effort to address it. I grok the issues to the core and the solution in the Inbox addresses them in the safest and smoothest way possible -- without duplication. Please let us move forward. I ask you to give the Inbox solution a try. - Chris Please find, attached, the package "Ma time objects". > Hi Chris, > I am leaning towards the "yet another class" approach. In the abstract, > because I think we are dealing with two different kinds of thing here, > and that would justify two classes. But in the concrete, and more > specifically with respect to the Date hash performance problem and > the time zone problem, here is why: > > If I look at what you did in the inbox for Date, you basically are > normalizing the offset from UTC in specifying the start time of > date. The duration of the date object is of no interest to you, so > you could (for your application) get rid of the duration instance > variable. Now if you look at the start time, it is a DateAndTime > with all instance variables zeroed out except for jdn. Thus the > only instance variable data in your Date object that carries any > useful information is the jdn, which is just a SmallInteger. > > This suggests that if you get rid of all the instance variables > that carry no information, what you are left with is a Date object > with a single instance variable for julianDayNumber. This would > be extremely fast and efficient for hashing and comparison, and > the meaning if this object could be understood with no confusion > regarding time spans, time zones, or durations. If you could have > a date object like this, it might very well solve your problems > with performance and timezone ambiguities. > > The interesting thing about this is that the stripped-down date > object that I am describing here is pretty much exactly the same > as the Date that was implemented in Squeak prior to Chronology > (i.e. in Squeak 3.6 and earlier). So if it turns out that the > Squeak 3.6 implementation of Date solves the performance and > timezone problems for applications like yours, then I think we > would be perfectly justified in adding another class to the system. > > I work with manufacturing systems in which I run into the concept > of a "scheduled production date". This sort of date has nothing > to do with durations, and very little to do with any actual point > in time. For example, a vehicle may be schedule to be manufactured > on a production date, and I want to be able to do things like find > the list of vehicles to be produced on a production date, or identify > parts and material supplies associated with that production date. But > I do not care if that "date" is 24 hours in duration, and I do not > care what hour of the day the scheduled production date begins on. > > I don't know if this is similar to the kinds of date you encounter > in a financial application, but I am envisioning financial transactions > being associated with a "transaction date" or something of that nature, > and I suspect this may be similar in some ways to the idea of a > "scheduled production date". If so, these are things that could be > very efficiently represented by a date object based on julian day > number, as opposed to the far more complicated representation of > date as a DateAndTime with Duration as found in Squeak today. > > Dave > Ma time objects-cmm.45.mcz (40K) Download Attachment Ma time objects-cmm.44.mcz (40K) Download Attachment |
In reply to this post by Chris Muller-3
> All tests pass except maybe not Timespan since its going to be purged.
> I'm going to chew on it for at least week -- if anyone wants to test > their app that'd be good too. why is timespan being purged. It is the reason I wrote Chronology. Cheers Brent |
And there's Chronos:
<http://chronos-st.blogspot.com/> <http://www.chronos-st.org/> Ken On 2012-02-05, at 11:32 AM, Brent Pinkney wrote: >> All tests pass except maybe not Timespan since its going to be purged. >> I'm going to chew on it for at least week -- if anyone wants to test >> their app that'd be good too. > > why is timespan being purged. It is the reason I wrote Chronology. > > Cheers > > Brent > |
In reply to this post by Brent Pinkney-2
Not Timespan. TimeStamp. OOPS -- that was a significant typo, sorry!
On Sun, Feb 5, 2012 at 12:32 PM, Brent Pinkney <[hidden email]> wrote: >> All tests pass except maybe not Timespan since its going to be purged. >> I'm going to chew on it for at least week -- if anyone wants to test >> their app that'd be good too. > > why is timespan being purged. It is the reason I wrote Chronology. > > Cheers > > Brent |
In reply to this post by Chris Muller-4
On Sun, Feb 05, 2012 at 11:56:06AM -0600, Chris Muller wrote:
> Hi Dave, thanks for the feedback. However, the yet-another-class > cannot actually satisfy my needs because I also require globalized > Minute, Hour, Month, Quarter and Year timespans. > > I totally understand and appreciate what you are saying about having a > "lean Date" a-la Squeak 3.6. Would you please look at the attached > packages? This package goes back to 2004, prior to the existence of > Chronology. It wraps a single LargeInteger to represent any > point-in-time precise to the millisecond. In fact, observe version 44 > of the package even went a step further and, rather than wrapping an > Integer, it even *inherited* from Integer -- e.g., each MaDate WAS an > Integer, with only behaviours. > > Guess what: It didn't perform any better than Chronology's 3 > SmallIntegers. (The benchmark results are published in the version > comments of the attached packages, check it out). > > Also, it created unnecessary converting complexities since there are > other areas of the system that use the standard Chronology class. expected a performance gain from wrapping a single LargeInteger, very interesting that it did not make a measurable difference. > > The other problem is: If we bring in yet-more-classes, where does > that leave Date, et al? They're still horribly broken, as you said in > your prior message. Unsuspecting Squeakers all over the world can be > drastically affected by this. This is not just my problem, it's > Squeak's problem, and it's a doozie -- wouldn't you say? I don't mean to say that it's horribly broken, just broken for cases involving durations that span daylight savings time transitions, leap seconds, and that sort of thing. This is not a good thing, but in practice it seems to affect a relatively small number of people. I'm not saying that is good, but it's not entirely horrible either, and making it better is difficult. > > The solution in the Inbox addresses all of the practical issues whilst > retaining a single, consistent, coherent and correct implementation of > time-objects for Squeak. It does not break Chronology. Dave, I've > been deep down this road and have spent a LOT of time and effort to > address it. I grok the issues to the core and the solution in the > Inbox addresses them in the safest and smoothest way possible -- > without duplication. Please let us move forward. I ask you to give > the Inbox solution a try. > > - Chris an image to experiment. Maybe I'm doing something wrong, but I get a lot of test failures and errors, see attached. I'm running on Linux with Cog, my computers' time zone is set for America/Detroit, and the Squeak timezone is set to a TimeZone(UTC). I have my TimeZoneDatabase package loaded also, but I force-loaded trunk/Kernel-eem.668 followed by inbox/Kernel-cmm.669 to make sure everything was consistent, and I evaluated "DateAndTime localTimeZone: TimeZone default" before running the tests. Are you seeing different results? My other concern as previously noted is that it does not seem to me to make logical sense to have "Date today" answer a duration with a start time of yesterday at 5 hours before midnight. Maybe that is not important in practice but it does not feel right to me. Please note that I do not mean to be casting a veto here. If there is general concensus that your inbox approach is a good thing, then you will have my full support. > > > Please find, attached, the package "Ma time objects". > > > Hi Chris, > > > I am leaning towards the "yet another class" approach. In the abstract, > > because I think we are dealing with two different kinds of thing here, > > and that would justify two classes. But in the concrete, and more > > specifically with respect to the Date hash performance problem and > > the time zone problem, here is why: > > > > If I look at what you did in the inbox for Date, you basically are > > normalizing the offset from UTC in specifying the start time of > > date. The duration of the date object is of no interest to you, so > > you could (for your application) get rid of the duration instance > > variable. Now if you look at the start time, it is a DateAndTime > > with all instance variables zeroed out except for jdn. Thus the > > only instance variable data in your Date object that carries any > > useful information is the jdn, which is just a SmallInteger. > > > > This suggests that if you get rid of all the instance variables > > that carry no information, what you are left with is a Date object > > with a single instance variable for julianDayNumber. This would > > be extremely fast and efficient for hashing and comparison, and > > the meaning if this object could be understood with no confusion > > regarding time spans, time zones, or durations. If you could have > > a date object like this, it might very well solve your problems > > with performance and timezone ambiguities. > > > > The interesting thing about this is that the stripped-down date > > object that I am describing here is pretty much exactly the same > > as the Date that was implemented in Squeak prior to Chronology > > (i.e. in Squeak 3.6 and earlier). So if it turns out that the > > Squeak 3.6 implementation of Date solves the performance and > > timezone problems for applications like yours, then I think we > > would be perfectly justified in adding another class to the system. > > > > I work with manufacturing systems in which I run into the concept > > of a "scheduled production date". This sort of date has nothing > > to do with durations, and very little to do with any actual point > > in time. For example, a vehicle may be schedule to be manufactured > > on a production date, and I want to be able to do things like find > > the list of vehicles to be produced on a production date, or identify > > parts and material supplies associated with that production date. But > > I do not care if that "date" is 24 hours in duration, and I do not > > care what hour of the day the scheduled production date begins on. > > > > I don't know if this is similar to the kinds of date you encounter > > in a financial application, but I am envisioning financial transactions > > being associated with a "transaction date" or something of that nature, > > and I suspect this may be similar in some ways to the idea of a > > "scheduled production date". If so, these are things that could be > > very efficiently represented by a date object based on julian day > > number, as opposed to the far more complicated representation of > > date as a DateAndTime with Duration as found in Squeak today. > > > > Dave > > Test Runner.2.png (64K) Download Attachment |
In reply to this post by Chris Muller-4
On Sun, Feb 5, 2012 at 1:23 PM, David T. Lewis <[hidden email]> wrote:
> On Sun, Feb 05, 2012 at 11:56:06AM -0600, Chris Muller wrote: >> Hi Dave, thanks for the feedback. However, the yet-another-class >> cannot actually satisfy my needs because I also require globalized >> Minute, Hour, Month, Quarter and Year timespans. >> >> I totally understand and appreciate what you are saying about having a >> "lean Date" a-la Squeak 3.6. Would you please look at the attached >> packages? This package goes back to 2004, prior to the existence of >> Chronology. It wraps a single LargeInteger to represent any >> point-in-time precise to the millisecond. In fact, observe version 44 >> of the package even went a step further and, rather than wrapping an >> Integer, it even *inherited* from Integer -- e.g., each MaDate WAS an >> Integer, with only behaviours. >> >> Guess what: It didn't perform any better than Chronology's 3 >> SmallIntegers. (The benchmark results are published in the version >> comments of the attached packages, check it out). >> >> Also, it created unnecessary converting complexities since there are >> other areas of the system that use the standard Chronology class. > > Thanks for sending the MA time objects attachments. I would have > expected a performance gain from wrapping a single LargeInteger, very > interesting that it did not make a measurable difference. I was very surprised too. > I don't mean to say that it's horribly broken, just broken for cases > involving durations that span daylight savings time transitions, leap > seconds, and that sort of thing. This is not a good thing, but in > practice it seems to affect a relatively small number of people. I'm > not saying that is good, but it's not entirely horrible either, and > making it better is difficult. The problems it creates are deeper than that. For your manufacturing system, you just wanted the resolution of a Date; not its start time. I don't know about the system, but for sake of illustration, I want to say it's a large system involving multiple machines providing input to the system. Now, imagine, one day, one machine in the system goes out for repair -- maybe it got its clock-battery replaced. It comes back on-line thinking it's in a different time-zone. Your manufacturing system does "Date today + 7 days" or maybe it just parses a date string: '2/15/2012' asDate. Your system is now being silently polluted with Dates that will not compare to the "productionDate" and the company misses a schedule. It's not about the number of people affected, it's the severity of the punishment to a system that never cared about timezone-sensitive Dates -- and shouldn't be required to unless it wants that. > I'm definitely looking at your inbox solution and have it loaded in > an image to experiment. Maybe I'm doing something wrong, but I get a > lot of test failures and errors, see attached. I'm running on Linux I'm sorry -- I forgot to tell everyone: After loading, please run the following expression: TimeZone withAllSubclassesDo: [ : each | each initialize ] I should have put that as a postscript.. After that you should not have any breakages except in TimeStamp because we want to purge that, not work on it. - Chris |
In reply to this post by Chris Muller-4
> My other concern as previously noted is that it does not seem to me
> to make logical sense to have "Date today" answer a duration with a > start time of yesterday at 5 hours before midnight. Maybe that is not > important in practice but it does not feel right to me. You can go back to localized dates with: Date localize However, "globalized" make perfect sense to me and I would think they would for you too in the context of the manufacturing system.. |
In reply to this post by Chris Muller-4
> I'm sorry -- I forgot to tell everyone: After loading, please run the
> following expression: > > TimeZone withAllSubclassesDo: [ : each | each initialize ] Timespan "arrrgh!" withAllSubclassesDo: [ : each | each initialize ] |
On Sun, Feb 05, 2012 at 02:51:08PM -0600, Chris Muller wrote:
> > I'm sorry -- I forgot to tell everyone: ?After loading, please run the > > following expression: > > > > ? ? ?TimeZone withAllSubclassesDo: [ : each | each initialize ] > > Timespan "arrrgh!" withAllSubclassesDo: [ : each | each initialize ] Ah, that's much better :) The errors are gone now, and failures reduced. I am getting five failures in TimeTransformTest. This is not unexpected, as the tests are from the TimeZoneDatabase package and I would fully expect to need to modify that if any time and date classes change in the image. I see six remaining failures in DateAndTimeLeapTest and one in one in StopWatchTest. I'll try to debug and give you some feedback some time after the SuperBowl ... in other words, probably not today ;-) Dave |
On Sun, Feb 05, 2012 at 05:36:12PM -0500, David T. Lewis wrote:
> On Sun, Feb 05, 2012 at 02:51:08PM -0600, Chris Muller wrote: > > > I'm sorry -- I forgot to tell everyone: ?After loading, please run the > > > following expression: > > > > > > ? ? ?TimeZone withAllSubclassesDo: [ : each | each initialize ] > > > > Timespan "arrrgh!" withAllSubclassesDo: [ : each | each initialize ] > > Ah, that's much better :) The errors are gone now, and failures reduced. > > I am getting five failures in TimeTransformTest. This is not unexpected, > as the tests are from the TimeZoneDatabase package and I would fully expect > to need to modify that if any time and date classes change in the image. > > I see six remaining failures in DateAndTimeLeapTest and one in one in > StopWatchTest. I'll try to debug and give you some feedback some time > after the SuperBowl ... in other words, probably not today ;-) A bit more feedback on test failures. If I set my time zone to UTC like this: "DateAndTime localTimeZone: TimeZone default" Then I see six failures in DateAndTimeLeapTest and one failure if StopwatchTest as described above. However, if I set my time zone to my current offset from UTC like this: DateAndTime localTimeZone: (TimeZone offset: (Duration minutes: Locale current offsetLocalToUTC) name: 'Local Time' abbreviation: 'LT'). Then in addition to those failures, I also see ten failures in TimeStampTest, one failure in DateTest, and one failure in YearTest. The failures overall seem to be related to comparing objects that have an offset from UTC (derived from the time zone offset) to objects that have zero offset. I am five hours from UTC, but presumably similar results would be seen in any time zone with a non-zero offset. Dave |
Thanks Dave. Hmm, I am not seeing any of errors you are. Could there
be a difference in our VM's or something else? How about would you run the tests with Squeak's great System Reporter so we can compare our contexts and figure out why failing for you? Here's mine with Image, MC Working Copies, VM General and SUnit. - Chris Image ----- /home/cmm/Chris/development/Squeak/_fixDate.image Squeak4.3 latest update: #11889 Current Change Set: Unnamed1 Monticello Working Copies ------------------------- 311Deprecated (nice.2) 39Deprecated (ar.19) Balloon (egp.19) BalloonTests (egp.2) * Collections (dtl.469) CollectionsTests (ul.186) * Compiler (nice.222, cmm.179) Compression (ul.31) * DeleteMe () EToys (ul.86) Exceptions (chc.36) Files (eem.116) FlexibleVocabularies (ar.12) Graphics (cmm.191) GraphicsTests (ar.29) Help-Squeak-Project (cmm.9) Help-Squeak-TerseGuide (dtl.2) HelpSystem-Core (ul.55) HelpSystem-Tests (ul.14) Installer-Core (ul.354) Kernel (cmm.670) KernelTests (cmm.214) Monticello (bf.493) MonticelloConfigurations (bf.100) Morphic (cmm.608) MorphicExtras (ul.103) MorphicTests (ar.18) Multilingual (ul.154) MultilingualTests (ul.15) Nebraska (ul.35) Network (ul.122) NetworkTests (ul.27) PackageInfo-Base (bf.57) PreferenceBrowser (bf.47) Protocols (ael.39) ReleaseBuilder (cmm.75) * Renamed () * SCFTCategory () SMBase (cmm.130) SMLoader (cmm.77) ST80 (dtl.138) SUnit (fbs.87) SUnitGUI (cmm.51) ScriptLoader (ul.333) Services-Base (ul.48) * ShoutCore (cmm.34, ul.34) Sound (ul.32) Squeak-Version (ar.4662) System (cwp.467) SystemChangeNotification-Tests (laza.18) SystemReporter (cmm.19) Tests (eem.140) ToolBuilder-Kernel (cmm.52) ToolBuilder-MVC (ul.29) ToolBuilder-Morphic (cmm.82) ToolBuilder-SUnit (cmm.15) Tools (laza.393) ToolsTests (ul.52) Traits (ul.289) TraitsTests (ar.9) TrueType (ul.19) TrunkScript (cmm.5) Universes (nice.45) VersionNumber (nice.3) VersionNumberTests (nice.3) XML-Parser (ael.35) Virtual Machine --------------- /opt/4dst/thirdparty/squeak/lib/squeak/3.9-7/squeak Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.104] Unix built on Jul 15 2011 15:22:56 Compiler: 4.1.2 20080704 (Red Hat 4.1.2-48) platform sources revision r2461 http://www.squeakvm.org/svn/squeak/branches/Cog CoInterpreter VMMaker.oscog-eem.104 uuid: 3ca0990a-ad74-44f1-bd92-a8be337813a1 Jul 15 2011 StackToRegisterMappingCogit VMMaker.oscog-eem.104 uuid: 3ca0990a-ad74-44f1-bd92-a8be337813a1 Jul 15 2011 SUnit Results ------------- 3091 run, 3068 passes, 10 expected failures, 13 failures, 0 errors, 0 unexpected passes Failed Tests ------------ (BecomeTest selector: #testBecomeIdentityHash) debug. (BlockContextTest selector: #testDecompile) debug. (ClosureCompilerTest selector: #testBlockDoitDecompilation) debug. (ExceptionTests selector: #testHandlerFromAction) debug. (FileStreamTest selector: #testPositionPastEndIsAtEnd) debug. (MCFileInTest selector: #testStWriter) debug. (MCMczInstallerTest selector: #testInstallFromFile) debug. (MCMczInstallerTest selector: #testInstallFromStream) debug. (PackageDependencyTest selector: #testMorphic) debug. (PackagePaneBrowserTest selector: #testSelectCategoryForClass) debug. (RWBinaryOrTextStreamTest selector: #testExisiting) debug. (ReleaseTest selector: #testNoObsoleteClasses) debug. (SocketTest selector: #testSendTimeout) debug. Errors ------ On Tue, Feb 7, 2012 at 6:58 PM, David T. Lewis <[hidden email]> wrote: > On Sun, Feb 05, 2012 at 05:36:12PM -0500, David T. Lewis wrote: >> On Sun, Feb 05, 2012 at 02:51:08PM -0600, Chris Muller wrote: >> > > I'm sorry -- I forgot to tell everyone: ?After loading, please run the >> > > following expression: >> > > >> > > ? ? ?TimeZone withAllSubclassesDo: [ : each | each initialize ] >> > >> > Timespan "arrrgh!" withAllSubclassesDo: [ : each | each initialize ] >> >> Ah, that's much better :) The errors are gone now, and failures reduced. >> >> I am getting five failures in TimeTransformTest. This is not unexpected, >> as the tests are from the TimeZoneDatabase package and I would fully expect >> to need to modify that if any time and date classes change in the image. >> >> I see six remaining failures in DateAndTimeLeapTest and one in one in >> StopWatchTest. I'll try to debug and give you some feedback some time >> after the SuperBowl ... in other words, probably not today ;-) > > A bit more feedback on test failures. If I set my time zone to UTC like this: > > "DateAndTime localTimeZone: TimeZone default" > > Then I see six failures in DateAndTimeLeapTest and one failure if StopwatchTest > as described above. > > However, if I set my time zone to my current offset from UTC like this: > > DateAndTime localTimeZone: (TimeZone > offset: (Duration minutes: Locale current offsetLocalToUTC) > name: 'Local Time' > abbreviation: 'LT'). > > Then in addition to those failures, I also see ten failures in TimeStampTest, > one failure in DateTest, and one failure in YearTest. > > The failures overall seem to be related to comparing objects that have > an offset from UTC (derived from the time zone offset) to objects that > have zero offset. > > I am five hours from UTC, but presumably similar results would be seen > in any time zone with a non-zero offset. > > Dave > > |
On Tue, Feb 07, 2012 at 08:16:24PM -0600, Chris Muller wrote:
> Thanks Dave. Hmm, I am not seeing any of errors you are. Could there > be a difference in our VM's or something else? > > How about would you run the tests with Squeak's great System Reporter > so we can compare our contexts and figure out why failing for you? > > Here's mine with Image, MC Working Copies, VM General and SUnit. Hi Chris, Here is the system report from a fresh image running on Linux with an interpreter VM. I started with a fresh 4.3 image, did an update from trunk, then loaded Kernel-cmm.670 from the inbox and ran the tests. TimeZoneDatabase is not loaded in this image, and I did not make any changes to default time zone setting. This is running on SuSE Linux, VM compiled 64-bit. Chronology test results are the same on Cog. I am in Michigan, 5 hours from GMT. HTH, Dave Image ----- /home/lewis/squeak/Squeak4.3/testdatestamp.1.image Squeak4.3 latest update: #11891 Current Change Set: Unnamed Monticello Working Copies ------------------------- 311Deprecated (nice.2) 39Deprecated (ar.19) Balloon (egp.19) BalloonTests (egp.2) * Collections (dtl.469) CollectionsTests (ul.186) Compiler (nice.222) Compression (ul.31) * DeleteMe () EToys (ul.86) Exceptions (chc.36) Files (eem.116) FlexibleVocabularies (ar.12) Graphics (cmm.191) GraphicsTests (ar.29) Help-Squeak-Project (cmm.9) Help-Squeak-TerseGuide (dtl.2) HelpSystem-Core (ul.55) HelpSystem-Tests (ul.14) Installer-Core (ul.354) * Kernel (cmm.670) * KernelTests (ul.213) Monticello (bf.493) MonticelloConfigurations (bf.100) Morphic (cmm.608) MorphicExtras (ul.103) MorphicTests (ar.18) Multilingual (ul.154) MultilingualTests (ul.15) Nebraska (ul.35) Network (ul.122) NetworkTests (ul.27) PackageInfo-Base (bf.57) PreferenceBrowser (bf.47) Protocols (ael.39) ReleaseBuilder (cmm.76) * Renamed () * SCFTCategory () SMBase (cmm.130) SMLoader (cmm.77) ST80 (dtl.138) SUnit (fbs.87) SUnitGUI (cmm.51) ScriptLoader (ul.333) Services-Base (ul.48) ShoutCore (ul.34) Sound (ul.32) Squeak-Version (ar.4662) * System (cwp.467) * SystemChangeNotification-Tests (laza.18) SystemReporter (cmm.19) * Tests (eem.140) ToolBuilder-Kernel (cmm.52) ToolBuilder-MVC (ul.29) ToolBuilder-Morphic (cmm.82) ToolBuilder-SUnit (cmm.15) Tools (laza.393) * ToolsTests (ul.52) Traits (ul.289) * TraitsTests (ar.9) TrueType (ul.19) TrunkScript (cmm.5) Universes (nice.45) VersionNumber (nice.3) VersionNumberTests (nice.3) XML-Parser (ael.35) Virtual Machine --------------- /usr/local/lib/squeak/4.8-2523/squeakvm Squeak3.11alpha of 2 February 2012 [latest update: #11890] Unix built on Feb 6 2012 22:19:51 Compiler: 4.5.0 20100604 [gcc-4_5-branch revision 160292] platform sources revision 2523 VMMaker versionString 4.8 SUnit Results ------------- 3091 run, 3046 passes, 7 expected failures, 31 failures, 2 errors, 5 unexpected passes Failed Tests ------------ (DateAndTimeLeapTest selector: #testAsDate) debug. (DateAndTimeLeapTest selector: #testAsMonth) debug. (DateAndTimeLeapTest selector: #testAsSeconds) debug. (DateAndTimeLeapTest selector: #testAsWeek) debug. (DateAndTimeLeapTest selector: #testAsYear) debug. (DateAndTimeLeapTest selector: #testMidnight) debug. (DateTest selector: #testStarting) debug. (ExceptionTests selector: #testHandlerFromAction) debug. (FileStreamTest selector: #testPositionPastEndIsAtEnd) debug. (MCFileInTest selector: #testStWriter) debug. (MCMczInstallerTest selector: #testInstallFromFile) debug. (MCMczInstallerTest selector: #testInstallFromStream) debug. (MirrorPrimitiveTests selector: #testMirrorAt) debug. (MirrorPrimitiveTests selector: #testMirrorEqEq) debug. (MirrorPrimitiveTests selector: #testMirrorInstVarAt) debug. (MirrorPrimitiveTests selector: #testMirrorPerform) debug. (MirrorPrimitiveTests selector: #testMirrorSize) debug. (PackageDependencyTest selector: #testMorphic) debug. (PackagePaneBrowserTest selector: #testSelectCategoryForClass) debug. (RWBinaryOrTextStreamTest selector: #testExisiting) debug. (ReleaseTest selector: #testNoObsoleteClasses) debug. (SocketTest selector: #testSendTimeout) debug. (SocketTest selector: #testSocketReuse) debug. (StandardSystemFontsTest selector: #testRestoreDefaultFonts) debug. (TimeStampTest selector: #testAccessing) debug. (TimeStampTest selector: #testConverting) debug. (TimeStampTest selector: #testDate) debug. (TimeStampTest selector: #testDateAndTime) debug. (TimeStampTest selector: #testMinusDays) debug. (TimeStampTest selector: #testMinusSeconds) debug. (TimeStampTest selector: #testMinusSecondsOverMidnight) debug. (TimeStampTest selector: #testPlusDays) debug. (TimeStampTest selector: #testPlusSeconds) debug. (TimeStampTest selector: #testPlusSecondsOverMidnight) debug. (TimespanDoTest selector: #testDatesDo) debug. (YearTest selector: #testCurrent) debug. Errors ------ (CompiledMethodTest selector: #testPerformCanExecutelongMethodWithTemps) debug. (CompiledMethodTest selector: #testPerformInSuperclassCanExecutelongMethodWithTemps) debug. |
> Here is the system report from a fresh image running on Linux with an
> interpreter VM. I started with a fresh 4.3 image, did an update from > trunk, then loaded Kernel-cmm.670 from the inbox and ran the tests. You need KernelTests-cmm.214 too. |
On Tue, Feb 07, 2012 at 09:41:12PM -0600, Chris Muller wrote:
> > Here is the system report from a fresh image running on Linux with an > > interpreter VM. I started with a fresh 4.3 image, did an update from > > trunk, then loaded Kernel-cmm.670 from the inbox and ran the tests. > > You need KernelTests-cmm.214 too. D'oh! My apologies. With the test updates loaded, The chronology tests are green with time zone set to UTC, and show nine failures in TimeStampTest and one failure in TimeStampDoTest. What time zone are you using (DateAndTime localTimeZone)? If your time zone offset has a zero duration, please try setting it to something else, and check the effect on the tests. Dave |
Free forum by Nabble | Edit this page |