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
