I do it by not adding time that way anymore. I use the DATEADD function
instead.
Function: DATEADD
Arguments: (datepart, number, date)
Returns: date
--------------------------------------------------------------------------------
Adds a specified number of days, weeks, months, or years to the date and
returns the new date.
Specify datepart using one of the following quoted values:
- Year—"year", "yy", or "yyyy"
- Month—"month", "mm", or "m"
- Day—"day", "dd", or "md"
- Week—"week", "wk", or "ww"
The date parameter is the date value to add to.
For example, this call adds 10 weeks to the date value in the date1 field:
DATEADD("week", 10, $date1$)
In your example it would be something like:
Set $New Start$ to value DATEADD( "day", $Day Interval$ * $IntervalCounter$,
$Start Date$ )
Set $New End$ to value DATEADD( "day", $Day Interval$ * $IntervalCounter$,
$End Date$ )
Fred
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Kemes, Lisa
Sent: Thursday, January 07, 2010 3:59 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST Issues
Wanted to clarify that we are on ARS 7.1 P7 with Windows 2003 and Oracle as our
DB.
Lisa
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of lisakemes
Sent: Thursday, January 07, 2010 4:55 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST Issues
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"
