Testing....
Lisa -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Kemes, Lisa Sent: Tuesday, January 12, 2010 2:51 PM To: [email protected] Subject: Re: DST Issues This topic seemed to go cold (brrrrr!) Is anyone else experiencing this? Again, we understand why this happens when we do a calculation on the date, but what happens when the second Sunday of March comes around and there's a March 15 12:00:00 AM date that was manually submitted and a March 15 1:00:00 AM that was calculated via adding days to the original date? The Epoch time in the Database reflects this same data as well. (the hour difference).... Come DST time, Remedy won't know which one was manually entered and which one was from a calculated date. Ugh! Lisa -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Shellman, David Sent: Monday, January 11, 2010 1:21 PM To: [email protected] Subject: Re: DST Issues Resending to correct a couple of typos. All, the issue is with adding seconds to Starting and Ending Dates for events that happen after the change to/from Daylight Savings time. The routines create multiple records by adding a fixed number of seconds for each new record. Say that we want to create 20 new records and each record is 7 days in the future. The filter loop would take the Start/End Date times of the first record and add 1 times 7 times 24 times 60 times 60 or 4,233,600 seconds. The next would be 2 times 7 times 24 times 60 times 60 or 8,467,200 seconds. This would continue for the set number of new records to be created. The problem is that the length of time is not a fixed length. One would think that there is always 86,400 seconds in a day. Interestingly there isn't. On the day that we change clocks ahead for Daylight savings time there are 82,800 (we shave off an hour from that day). On the day that we change clocks back for Standard time there are 90,000 (we remove an hour for that day). This is what's causing the issue for us. Does DATEADD account for these two shortened/lengthened days? Dave -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Grooms, Frederick W Sent: Monday, January 11, 2010 12:20 PM To: [email protected] Subject: Re: DST Issues Question... What happens if you set the date on the PC to 3/15/2010? What does the manually entered show? What does the calculated show? Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Kemes, Lisa Sent: Monday, January 11, 2010 9:32 AM To: [email protected] Subject: Re: DST Issues Thanks Dave, I was hoping that the display would be different, but the database date would be the same. But this isn't the case. When I add a date to the system manually 3/15/2010 12:00:00 AM it's posted to my client as the same date and time and in the Database as the same Date and Time (but in Epoch of course). When I use the DATEADD function to add 63 days to the date 1/11/2010 12:00:00 AM it posts to the client (and to the database) as 3/15/2010 1:00:00 AM. Why the difference then between adding a date/time manually and adding to a date using the DATEADD function? Shouldn't they both show up as 3/15/2010 1:00:00 AM then? Lisa -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of David Sanders Sent: Friday, January 08, 2010 10:20 AM To: [email protected] Subject: Re: DST Issues Hi Lisa This is the Remedy equivalent of relativity theory. What date/time you see depends upon your current date/time as far as DST is concerned. Let me try to explain. Dates in Remedy are stored as epoch time - the number of seconds since 12AM 1/1/1970 GMT. When you set your regional settings, you are identifying an offset from GMT that the client uses to display the date/time in your current timezone. When DST kicks in, effectively, your offset from GMT is changed by one hour. For example, you might now be 7 hours behind GMT instead of 8 hours behind. All dates are then displayed in the new timezone offset. When you look at date/times in the future, you are looking at them from your current timezone offset, so dates after DST kicks in will appear one hour out. Later in the year, these dates will be displayed correctly, but dates from before the DST change will be displayed one hour out the other way. The Remedy client makes no attempt to apply a different timezone offset to past or future dates when it displays them - it always uses the current defined offset. So, in other words, I think your date/time calculations are correct, and by the time you get to May or August, those times will be displayed correctly. HTH David Sanders Remedy Solution Architect Enterprise Service Suite @ Work ========================== tel +44 1494 468980 mobile +44 7710 377761 email [email protected] web http://www.westoverconsulting.co.uk -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of lisakemes Sent: 07 January 2010 21:55 To: [email protected] 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! _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
