You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@sandglass-software.com> on 2011/02/01 07:25:47 UTC
Re: TimeOfDayRange in Temporal Expressions
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, adrian.crum@sandglass-software.com 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 <sc...@hotwaxmedia.com>:
>
>> 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
>>>>
>>
>>
>
>
>
Re: TimeOfDayRange in Temporal Expressions
Posted by Adrian Crum <ad...@sandglass-software.com>.
That's correct. The idea is to combine it with other expressions, and
then it serves as a "window" of date/times. There are code comments that
explain it in detail.
-Adrian
On 2/1/2011 10:54 PM, Scott Gray wrote:
> 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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>>>
>>>>>>> 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, adrian.crum@sandglass-software.com 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<ad...@sandglass-software.com>:
>>>>>>>>
>>>>>>>>> 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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>
>>>>>>
Re: TimeOfDayRange in Temporal Expressions
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>>
>>>>>> 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, adrian.crum@sandglass-software.com 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<ad...@sandglass-software.com>:
>>>>>>>
>>>>>>>> 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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>
Re: TimeOfDayRange in Temporal Expressions
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>
>>>>> 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, adrian.crum@sandglass-software.com 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<ad...@sandglass-software.com>:
>>>>>>
>>>>>>> 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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
Re: TimeOfDayRange in Temporal Expressions
Posted by Adrian Crum <ad...@sandglass-software.com>.
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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>
>>>> 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, adrian.crum@sandglass-software.com 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<ad...@sandglass-software.com>:
>>>>>
>>>>>> 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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
Re: TimeOfDayRange in Temporal Expressions
Posted by Adrian Crum <ad...@sandglass-software.com>.
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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>
>>> 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, adrian.crum@sandglass-software.com 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<ad...@sandglass-software.com>:
>>>>
>>>>> 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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>
>>>>
>>>>
>>>
>>
>>
Re: TimeOfDayRange in Temporal Expressions
Posted by Scott Gray <sc...@hotwaxmedia.com>.
> 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, adrian.crum@sandglass-software.com 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 <sc...@hotwaxmedia.com>:
>
>> 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, adrian.crum@sandglass-software.com 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 <ad...@sandglass-software.com>:
>>>
>>>> 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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>>>>
>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: TimeOfDayRange in Temporal Expressions
Posted by ad...@sandglass-software.com.
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 <sc...@hotwaxmedia.com>:
> 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, adrian.crum@sandglass-software.com 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 <ad...@sandglass-software.com>:
>>
>>> 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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>>>
>>>>>>> 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
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>
>>
>>
>>
>
>
Re: TimeOfDayRange in Temporal Expressions
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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, adrian.crum@sandglass-software.com 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 <ad...@sandglass-software.com>:
>
>> 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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>>
>>>>>> 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
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>
>
>
>
Re: TimeOfDayRange in Temporal Expressions
Posted by ad...@sandglass-software.com.
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 <ad...@sandglass-software.com>:
> 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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>>
>>>>> 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
>>>>>>>
>>>>>
>>>>
>>>>
>
Re: TimeOfDayRange in Temporal Expressions
Posted by Adrian Crum <ad...@sandglass-software.com>.
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, adrian.crum@sandglass-software.com 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<sc...@hotwaxmedia.com>:
>>>
>>>> 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
>>>>>>
>>>>
>>>
>>>
Re: TimeOfDayRange in Temporal Expressions
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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, adrian.crum@sandglass-software.com 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 <sc...@hotwaxmedia.com>:
>>
>>> 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
>>>>>
>>>
>>>
>>
>>
>>