Not sure if this is the same thing (we are NOT dealing with Business Time in this scenario), but wanted to see what people were doing in this situation.
I have an On Call System that allows the user to create multiple records if they are on call every XX number of days. So if someone were to type in a Start Date of 2/2/2010 12:00:00 AM and an End Date of 2/3/2010 12:00:00 AM and add multiple records every 100 days for 3 times, I get: Start 2/2/2010 12:00:00 AM End 2/3/2010 12:00:00 AM Start 5/13/2010 1:00:00 AM End 5/14/2010 1:00:00 AM Start 8/21/2010 1:00:00 AM End 8/22/2010 1:00:00 AM Start 11/29/2010 12:00:00 AM End 11/30/2010 12:00:00 AM (I'm adding ((((60 * 60) * 24) * $Day Interval$) * $IntervalCounter$) to the Start Date and End Date) We understand WHY this happens, but wondering what people do about this? Once March 14th rolls around, the times in May and August will still be 1:00:00 AM correct? (the customer wants 12:00:00 AM) I checked the database (hoping that in the DB it was correct and the it was only displaying in the client differently) but the Database is also showing these dates and times. We are thinking about creating a separate table to clarify DST Dates and Times and if a date falls on a certain date and time, subtracting or adding an hour to the Start Date or End Date. UGH! ----------------------------------------------------------------------- David: Have a look at Test3, it appears that the business time 1 subtract function, using a unit of days, has a different result than all other units; it is off by 1 hour. Maybe this is being calculated incorrectly? * Test 3 Business Time Type: Business Time 1 TestID: 000000000000202 Start: 3/10/2007 11:00:00 PM End: 3/11/2007 11:00:00 PM Diff Seconds: 86400 Diff Minutes: 1440 Diff Hours: 24 Diff Days: 1 Workday: 24 Hr Tag Holiday: 24 Hr Tag Result of Add to Start (Seconds): 3/11/2007 11:00:00 PM Result of Add to Start (Minutes): 3/11/2007 11:00:00 PM Result of Add to Start (Hours): 3/11/2007 11:00:00 PM Result of Add to Start (Days): 3/11/2007 11:00:00 PM Result of Subtract from End (Seconds): 3/10/2007 11:00:00 PM Result of Subtract from End (Minutes): 3/10/2007 11:00:00 PM Result of Subtract from End (Hours): 3/10/2007 11:00:00 PM Result of Subtract from End (Days): 3/11/2007 12:00:00 AM * DB Values: REQUEST_ID: 000000000000202 STARTDATE: 1173585600 ENDDATE: 1173668400 ENDDATE-STARTDATE: 82800 Axton Grams On 3/6/07, Easter, David <david_eas...@bmc.com> wrote: > Business Time is not DST aware. This has been true for quite some time > now, and is probably why you're seeing the issue. Basically, Business > Time doesn't know that the change from Standard to DST is a 23 hour day > nor that from DST to Standard is a 25 hour day. It's unrelated to the > changes in DST rules for 2007 - i.e. folks have been dealing with this for > years. > > This is somewhat obliquely mentioned in the tech bulletin: > > "In addition, as happens during any DST event, when DST begins, the day > loses one hour (hour interchange of −1). At this date, a full hour is > skipped and does not exist either before or after the transition, so this > date includes only 23 hours. Workflow that is designed to fire only > during that lost hour may not fire properly. However, since this issue > occurs during every DST event, we expect that customers that would be > affected by this event have already compensated for this issue. This > issue is not related to AR System and thus affects all versions of AR > System." > > Due to the raised level of concern on this issue, BMC is looking into > adding more intelligence into Business Time in the next release (i.e. > 7.1.00) to deal with DST and time zones more gracefully. One may also be > able to write some workflow that influences Business Time results to > compensate for the lost (or gained) hour during the switch between > Standard and Daylight. > > Thanks, > > -David J. Easter > Sr. Product Manager, Service Management Business Unit > BMC Software, Inc. > > The opinions, statements, and/or suggested courses of action expressed in > this E-mail do not necessarily reflect those of BMC Software, Inc. My > voluntary participation in this forum is not intended to convey a role as > a spokesperson, liaison or public relations representative for BMC > Software, Inc. > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arsl...@arslist.org] On Behalf Of Axton > Sent: Tuesday, March 06, 2007 4:56 PM > To: arslist@ARSLIST.ORG > Subject: DST Issues > > Reposting this because I've seen no replies and wasn't sure if it went > into a black hole today when no posts were being sent. I really need a > sanity check on this to make sure I'm not out of whack. > > Axton > > I am seeing some strange results in my DST testing in regards to business > time. > > Environment: > ARServer 7.0.01 patch 001 > SunOS 5.9 Generic_118558-26 > Mid-Tier 7.0.01 patch 001 > IBM WebSphere Application Server/6.0 > IBM Java 1.4.2_11 > > I took 2 dates, a start and end date, performed a business time diff, then > added the diff to the start date and subtracted it from the end date; all > BT calculations are done in filters on the server side. > These are some of the results of the tests: > > Here are the scenarios I ran using the Mid-Tier as my client, just to > avoid potential client/MS DST issues: > > * Test 0 > Business Time Type: Business Time 1 > TestID: 000000000000109 > Start: 3/10/2007 1:00:00 PM > End: 3/10/2007 2:00:00 PM > Diff Seconds: 3600 > Diff Minutes: 60 > Diff Hours: 1 > Workday: 24 Hr Tag > Holiday: 24 Hr Tag > Result of Add to Start: 3/10/2007 2:00:00 PM (for all 3 units) Result of > Subtract from End: 3/10/2007 1:00:00 PM (for all 3 units) > * DB Values: > REQUEST_ID: 000000000000109 > STARTDATE: 1173549600 > ENDDATE: 1173553200 > ENDDATE-STARTDATE: 3600 > > This one looks good. > > * Test 1 > TestID: 000000000000111 > Business Time Type: Business Time 1 > Start: 3/11/2007 1:00:00 AM > End: 3/11/2007 3:00:00 AM > Diff Seconds: 7200 > Diff Minutes: 120 > Diff Hours: 2 > Workday: 24 Hr Tag > Holiday: 24 Hr Tag > Result of Add to Start: 3/11/2007 3:00:00 AM (for all 3 units) Result of > Subtract from End: 3/11/2007 1:00:00 AM (for all 3 units) > * DB Values: > REQUEST_ID: 000000000000111 > STARTDATE: 1173592800 > ENDDATE: 1173596400 > ENDDATE-STARTDATE: 3600 > > Something is off here; db difference returns 3600 seconds, BT diff returns > 7200 seconds. At least the client/server translation appears to be > working correctly. > > * Test 2 > TestID: 000000000000115 > Business Time Type: Business Time 1 > Start: 3/11/2007 1:00:00 AM > End: 3/11/2007 2:00:00 AM > Diff Seconds: 3600 > Diff Minutes: 60 > Diff Hours: 1 > Workday: 24 Hr Tag > Holiday: 24 Hr Tag > Result of Add to Start: 3/11/2007 2:00:00 AM (for all 3 units) Result of > Subtract from End: 3/11/2007 1:00:00 AM (for all 3 units) > * DB Values: > REQUEST_ID: 000000000000115 > STARTDATE: 1164780000 > ENDDATE: 1164783600 > ENDDATE-STARTDATE: 3600 > > This one looks good. > > While the add and subtract put the date back at the expected values, the > diffs seem to be off for test 1 (which covers the DST change). > > For Test 1, I would expect to see 1 hour as the result of the business > time diff (1:00-1:59, then jump to 3:00). > > This is very odd. Can someone give me a sanity check on what I think I > should be seeing? The same workflow was used to generate all the test > results (filters on 1 form where I provide the BT version, > holiday/workday/segments, start date, and end date). The calculations are > done properly when using the time difference provided by the diff, but I > am concerned this will cause issues for time calculations where the offset > is provided as a constant (e.g. 3/11/2007 1:00:00 AM + 4 hours will result > in 4/2/2006 5:00:00 AM, when it should result in > 4/2/2006 6:00:00 AM. The 1 hour increments would follow this pattern: > 1-3, 3-4, 4-5, 5-6), such as SLA's that use absolute time, e.g., 4 hrs on > a 24hr business workday. > > If you look at Test 1, it appears the values are written to the db > properly in GMT time, and if I subtract those times (epoch/integers) in > the db I get back 3600 (what I expected), but business time 1 gives me a > difference of 7200 seconds (2 hours) for the same start/end times. > > > Here is another interesting one. To reiterate, these tests were performed > by taking two times, calculating the difference between the two times > using Application-Business-Time-Diff; then adding that diff to the start > time and subtracting that diff from the end time. > > * Test 3 > Business Time Type: Business Time 1 > TestID: 000000000000202 > Start: 3/10/2007 11:00:00 PM > End: 3/11/2007 11:00:00 PM > Diff Seconds: 86400 > Diff Minutes: 1440 > Diff Hours: 24 > Diff Daus: 1 > Workday: 24 Hr Tag > Holiday: 24 Hr Tag > Result of Add to Start (Seconds): 3/11/2007 11:00:00 PM Result of Add to > Start (Minutes): 3/11/2007 11:00:00 PM Result of Add to Start (Hours): > 3/11/2007 11:00:00 PM Result of Add to Start (Days): 3/11/2007 11:00:00 PM > Result of Subtract from End (Seconds): 3/10/2007 11:00:00 PM Result of > Subtract from End (Minutes): 3/10/2007 11:00:00 PM Result of Subtract from > End (Hours): 3/10/2007 11:00:00 PM Result of Subtract from End (Days): > 3/11/2007 12:00:00 AM > * DB Values: > REQUEST_ID: 000000000000202 > STARTDATE: 1173585600 > ENDDATE: 1173668400 > ENDDATE-STARTDATE: 82800 > > It appears in this case, that the business time subtract, when using the > unit of days, properly accounts for the DST changes (the result has a 1 hr > offset from the original time), when all other units do not; at the same > time, the business time add of 1 day does not work consistently with > subtract with a unit of "days", or I would have seen > 3/12/2007 12:00:00 AM as the return value. > > Notice that the db value for the time difference (end-start) does not > match that of the business time calculation > (Application-Business-Time-Diff). > > This is just getting better and better. > > Axton Grams > -- View this message in context: http://old.nabble.com/DST-Issues-tp9344896p27067701.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
