BTW, wouldn't the DateRange expression suffer the same issue with next()? The code appears to just return the passed in calendar if the expression includes its date.
Regards Scott On 2/02/2011, at 7:45 PM, Scott Gray wrote: > Ah yes but I only need the includesDate() method :-) > > I appreciate your input and understand what you are suggesting but > unfortunately I'm struggling to see past temporal expressions using > TimeOfDayRange simply because it seems like the simplest and most direct > solution. I'm going to setup a quick prototype tonight and if it works then > I'll go with it and if not then I'll be back to discuss your proposals :-) > > Thanks > Scott > > On 2/02/2011, at 7:27 PM, Adrian Crum wrote: > >> Btw, the reason the TimeOfDay range didn't work was because of the next() >> method. If the expression includes a minute component and an hour component, >> what is being incremented when next() is called? It ended up being ambiguous >> and unreliable. >> >> -Adrian >> >> On 2/1/2011 10:22 PM, Adrian Crum wrote: >>> Fair enough. >>> >>> Initially I suggested using a temporal expression plus duration to solve >>> the problem. You said there will be errors during DST transitions - that's >>> true. Then I said you would need a start temporal expression and an end >>> temporal expression. But I realized this would be too much work for the end >>> user because it would be too complicated. So I suggested using temporal >>> expression with duration, plus check for a DST transition using the >>> TimeZone object. This would be the quickest way to get it implemented, but >>> it's a bad long term strategy because it doesn't consider other billing >>> scenarios. So I started sketching out some code that would handle >>> arbitrarily complex billing scenarios and gave you what I had so far, in >>> case you were interested. >>> >>> To summarize: since you're pressed for time, the temporal expression plus >>> duration plus DST check would be your best choice. The code I sketched out >>> doesn't have the DST check because the ending day and time is specified - >>> instead of using a duration. In the meantime I'm working on the "ideal" >>> version - because I will need it for the project I'm working on. >>> >>> Sorry for the confusion. >>> >>> -Adrian >>> >>> On 2/1/2011 5:05 PM, Scott Gray wrote: >>>>> Each object executes a loop that tests to see if the date falls within >>>>> its range >>>> Isn't this exactly what job temporal expressions are intended for? Twice >>>> now you've told me that something isn't suitable (TimeOfDayRange and >>>> temporal expressions themselves) but without making any effort to explain >>>> why, if I have a hammer and something that looks like a nail then simply >>>> saying "that isn't a nail" isn't going to convince me. I need you to tell >>>> me that the nail is actually made of rubber and hitting it will just smash >>>> my thumb :-) >>>> >>>> Regards >>>> Scott >>>> >>>> On 2/02/2011, at 9:24 AM, [email protected] wrote: >>>> >>>>> Actually, temporal expressions should not be used because they aren't the >>>>> right tool for the job. Here is what I sketched out initially, you can >>>>> use it if you want: >>>>> >>>>> We need a data structure that includes a starting day of week and time, >>>>> an ending day of week and time, a billing rate, and a billing increment. >>>>> The structure also has a single method to compute billing. The structures >>>>> are assembled in chronological order in a chain or array. >>>>> >>>>> A second structure is used as an argument for the first structure's >>>>> billing method. It includes Dates representing the start and end of the >>>>> billing period, an accumulator for the billed amount, and an optional >>>>> List to keep track of the various rates and quantities that were used to >>>>> compute the total. >>>>> >>>>> This second structure is initialized and passed to the first object in >>>>> the chain or is passed to each object in the array. Each object executes >>>>> a loop that tests to see if the date falls within its range, and if it >>>>> does, money is added to the accumulator. The billing period start date is >>>>> incremented by the increment amount and the loop repeats. When the date >>>>> falls outside the object's range, control is passed to the next object in >>>>> the array/chain. When the billing period start date equals the billing >>>>> period end date, the process stops. >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> Quoting Scott Gray<[email protected]>: >>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> The reasons you've mentioned below for why temporal expressions >>>>>> shouldn't be used simply don't apply to my situation. All I have to >>>>>> support is an admin defining the rate windows for a tiny date range >>>>>> (maybe 3-10 days) and then apply pricing based on what windows a start >>>>>> time + duration fall into. Aside from making sure the appropriate >>>>>> timezone is applied and nothing quirky happens around DST, I have no >>>>>> other additional complexities in my requirements. >>>>>> >>>>>> I would love to be able to collaborate with you on a more robust >>>>>> implementation but I simply don't have the time, unfortunately I only >>>>>> have hours available to design and implement a solution rather than days >>>>>> or weeks. Thanks for sharing your thoughts though, I really appreciate >>>>>> it. >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> On 2/02/2011, at 6:15 AM, [email protected] wrote: >>>>>> >>>>>>> Scott, >>>>>>> >>>>>>> I don't think temporal expressions alone will do the job. Here's why: >>>>>>> >>>>>>> The type of billing you describe is what we call in the US a "shift >>>>>>> differential." There are other factors that can affect billing too, >>>>>>> like billing overtime if an employee works more than 8 hours in one day >>>>>>> or 40 hours in one week. In addition, you might want to bill overtime >>>>>>> for an employee who works on a holiday. >>>>>>> >>>>>>> These same rules could be applied to payroll to generate time sheets. >>>>>>> >>>>>>> I'm thinking we need something more comprehensive and flexible than >>>>>>> what you described. >>>>>>> >>>>>>> I have experience in writing software for these types of scenarios. If >>>>>>> you are interested in collaborating on a design, I would be happy to >>>>>>> help. If so, let's open a Jira issue and start sharing ideas. >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> >>>>>>> Quoting Adrian Crum<[email protected]>: >>>>>>> >>>>>>>> I'm still scratching my head on this one. I will need a similar >>>>>>>> implementation in the near future, so I'm interested in helping with >>>>>>>> the design. I'm reading Fowler's Analysis Patterns (7.7) to see what >>>>>>>> his solution is. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> On 2/1/2011 2:09 AM, Scott Gray wrote: >>>>>>>>> It's all a little bit complicated and I keep wondering to myself why >>>>>>>>> I don't just implement a TimeOfDayRange** to get me past it. >>>>>>>>> Basically worker time is orderable in 15 minute increments with a >>>>>>>>> start time and a duration and I then have to break that duration down >>>>>>>>> into the relevant rates. I was hoping to just be able to iterate >>>>>>>>> over each ordered 15 minute intervals and test them against each of >>>>>>>>> the 3 temporal expressions (standard, overtime, double time) to >>>>>>>>> determine which window each falls within. >>>>>>>>> >>>>>>>>> I can't seem to understand why DateRange, HourRange and MinuteRange >>>>>>>>> are okay but a TimeOfDayRange is a bad design? >>>>>>>>> >>>>>>>>> ** I just noticed the deprecated implementation in 10.04, and it >>>>>>>>> seems to do exactly what I had in mind, even if the >>>>>>>>> design/implementation is flawed do you think it might work for my >>>>>>>>> situation? >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> On 1/02/2011, at 7:25 PM, Adrian Crum wrote: >>>>>>>>> >>>>>>>>>> Thinking about this more... >>>>>>>>>> >>>>>>>>>> It might be easier to leverage the existing temporal expression + >>>>>>>>>> time duration code, and simply perform a check to see if a DST >>>>>>>>>> transition occurred during the billing period. You can perform that >>>>>>>>>> check by using the TimeZone object. >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> On 1/31/2011 11:05 AM, [email protected] wrote: >>>>>>>>>>> That is an interesting problem to solve. At first glance it seems >>>>>>>>>>> you would need separate event start and event end expressions. >>>>>>>>>>> >>>>>>>>>>> -Adrian >>>>>>>>>>> >>>>>>>>>>> Quoting Scott Gray<[email protected]>: >>>>>>>>>>> >>>>>>>>>>>> Thanks Adrian, I had a feeling that would be the case but just >>>>>>>>>>>> wanted to double check. >>>>>>>>>>>> >>>>>>>>>>>> What I am trying to do is model different ranges of time in which >>>>>>>>>>>> a customer would get charged a given rate (standard, overtime, >>>>>>>>>>>> double time). The only concern I have with using a rate start >>>>>>>>>>>> time and duration is daylight saving, if a window were to begin at >>>>>>>>>>>> midnight and end at 8.30am then using an 8.5hr duration wouldn't >>>>>>>>>>>> work correctly when daylight savings starts and ends. So for me >>>>>>>>>>>> it's less important how long a window lasts but rather at what >>>>>>>>>>>> specific time it closes. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Scott >>>>>>>>>>>> >>>>>>>>>>>> HotWax Media >>>>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>>>> >>>>>>>>>>>> On 1/02/2011, at 3:03 AM, Adrian Crum wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Scott, >>>>>>>>>>>>> >>>>>>>>>>>>> The TimeOfDay range expression was a bad design and it didn't >>>>>>>>>>>>> work, so it was replaced with MinuteRange and HourRange. >>>>>>>>>>>>> >>>>>>>>>>>>> It looks like you might be trying to combine a temporal >>>>>>>>>>>>> expression with a duration. Does the event keep repeating from >>>>>>>>>>>>> 05:00 to 08:30? Or does it occur at 05:00 and have a duration of >>>>>>>>>>>>> 3.5 hours? Keep in mind the Temporal Expression indicates when an >>>>>>>>>>>>> event occurs, not how long it lasts. >>>>>>>>>>>>> >>>>>>>>>>>>> -Adrian >>>>>>>>>>>>> >>>>>>>>>>>>> On 1/30/2011 6:47 PM, Scott Gray wrote: >>>>>>>>>>>>>> Hi Adrian (I assume you're the only one that knows...), >>>>>>>>>>>>>> >>>>>>>>>>>>>> In the original jira issue for the temporal expression >>>>>>>>>>>>>> implementation there was mention of a TimeOfDayRange expression >>>>>>>>>>>>>> (http://markmail.org/message/pz2i3kzavcnee4ca) but I can't seem >>>>>>>>>>>>>> to find a corresponding class in the trunk? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm looking to model something along the lines of: >>>>>>>>>>>>>> Intersection: >>>>>>>>>>>>>> DayOfWeekRange(Monday, Friday) >>>>>>>>>>>>>> Union: >>>>>>>>>>>>>> TimeOfDayRange(5:00, 08:30) >>>>>>>>>>>>>> TimeOfDayRange(17:30, 22:30) >>>>>>>>>>>>>> >>>>>>>>>>>>>> At the moment the only way I can see to do this is with >>>>>>>>>>>>>> something quite complex like: >>>>>>>>>>>>>> Intersection: >>>>>>>>>>>>>> DayOfWeekRange(Monday, Friday) >>>>>>>>>>>>>> Union: >>>>>>>>>>>>>> Union: >>>>>>>>>>>>>> HourOfDayRange(5:00, 08:00) >>>>>>>>>>>>>> Intersection: >>>>>>>>>>>>>> HourOfDayRange(08:00, 08:00) >>>>>>>>>>>>>> MinuteOfDyRange(0, 30) >>>>>>>>>>>>>> Union: >>>>>>>>>>>>>> Intersection: >>>>>>>>>>>>>> HourOfDayRange(17:00, 17:00) >>>>>>>>>>>>>> MinuteOfDyRange(30, 59) >>>>>>>>>>>>>> HourOfDayRange(18:00, 22:00) >>>>>>>>>>>>>> Intersection: >>>>>>>>>>>>>> HourOfDayRange(22:00, 22:00) >>>>>>>>>>>>>> MinuteOfDyRange(0, 30) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Assuming the above is even correct, is it my only option in the >>>>>>>>>>>>>> current implementation? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Scott >>>>>>>>>>>>>> >>>>>>>>>>>>>> HotWax Media >>>>>>>>>>>>>> http://www.hotwaxmedia.com >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >
smime.p7s
Description: S/MIME cryptographic signature
