About the new Date
Locked
12
12
About the new Date
 
|
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
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 |
Re: About the new Date
|
|
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 |
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
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 > > |
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
Re: About the new Date
|
|
| Free forum by Nabble | Edit this page |