Re: DST issues today RESOLVED
Doug, I'm curious now so I went into the WUT and under Options | Locale | Time I changed the Time zone to America/New_York and I get the same problem. All my date fields show time one hour earlier. But log out of the WUT and log into Mid Tier and the time comes out correct on the same forms, same records. And checking the User Preferences record in Mid Tier shows America/New_York in the time zone. Log back into the WUT and the time is off by an hour. Clear the value in the User preference record on Mid Tier client, relogin to WUT and the time is correct. So my guess is there is something wrong with my Windows 7 on my laptop causing a local issue. Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Mueller, Doug Sent: Monday, March 11, 2013 3:31 PM To: arslist@ARSLIST.ORG Subject: EXTERNAL: Re: DST issues today RESOLVED John, Not sure why your setting was this way. I would just guess someone selected the wrong choice by accident. They saw it was a -5 timezone and thought that was fine. As to why this was right before and not today? Well, if you look up the COT timezone (this is the abbreviation for the America/Bogota timezone) you will see that they are not obeying daylight saving time. So, they were just fine during the winter, but when daylight saving time kicks in, they don't change and other areas change so it seems like the time is "wrong". So, just something to be aware of. All you contacts in Bogota are now an hour different from you than they were last week. Schedule meetings accordingly! I will note that the system worked exactly as it was supposed to. It used your preference setting to display things and your preference is to an area without daylight saving time. I hope this helps, Doug Mueller -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Reiser, John J Sent: Monday, March 11, 2013 10:47 AM To: arslist@ARSLIST.ORG Subject: Re: DST issues today RESOLVED Fred, They probably have. They don't inform me when they make "Security required" updates to the server. I tried a few more clients. Mid Tier via a browser running on my local PC shows the correct time. Mid Tier running a browser on the server in a Remote Desktop window shows the wrong time (Standard Time). And again, the WUT running on my PC shows the wrong time. I don't have a WUT on the server. I went to some other PC's and these folks got the correct time. I checked my Preferences and had America/Bogota in the settings which I thought would conflict with the Mid Tier. Anyway, I cleared the setting in Time settings on the WUT and everything works now. Don't know how or why the Time Zone was set to America/Bogota or why it didn't affect the time before Sunday. Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Monday, March 11, 2013 11:49 AM To: arslist@ARSLIST.ORG Subject: EXTERNAL: Re: DST issues today My first question would be has anyone updated the Java on your server since the last time change? I think that the ARS server uses a Java routine to determine the timestamp. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Reiser, John J Sent: Monday, March 11, 2013 10:26 AM To: arslist@ARSLIST.ORG Subject: DST issues today Hello Listers, ARS 7.6.03 MS SQL 2005 MS OS Windows 2003 Enterprise Is anyone who has gone through the change to DST experiencing time stamp issues? My client machine and my server are displaying the correct Daylight Saving Time but the timestamp in the create date field on my system are still coming up as Eastern Standard Time. Haven't had an issue like this for many years now and it's kind of thrown me off. Any ideas out there? Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me ___ UNSUBSCRIBE or access ARSlist Archives at ww
Re: DST issues today RESOLVED
John, Not sure why your setting was this way. I would just guess someone selected the wrong choice by accident. They saw it was a -5 timezone and thought that was fine. As to why this was right before and not today? Well, if you look up the COT timezone (this is the abbreviation for the America/Bogota timezone) you will see that they are not obeying daylight saving time. So, they were just fine during the winter, but when daylight saving time kicks in, they don't change and other areas change so it seems like the time is "wrong". So, just something to be aware of. All you contacts in Bogota are now an hour different from you than they were last week. Schedule meetings accordingly! I will note that the system worked exactly as it was supposed to. It used your preference setting to display things and your preference is to an area without daylight saving time. I hope this helps, Doug Mueller -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Reiser, John J Sent: Monday, March 11, 2013 10:47 AM To: arslist@ARSLIST.ORG Subject: Re: DST issues today RESOLVED Fred, They probably have. They don't inform me when they make "Security required" updates to the server. I tried a few more clients. Mid Tier via a browser running on my local PC shows the correct time. Mid Tier running a browser on the server in a Remote Desktop window shows the wrong time (Standard Time). And again, the WUT running on my PC shows the wrong time. I don't have a WUT on the server. I went to some other PC's and these folks got the correct time. I checked my Preferences and had America/Bogota in the settings which I thought would conflict with the Mid Tier. Anyway, I cleared the setting in Time settings on the WUT and everything works now. Don't know how or why the Time Zone was set to America/Bogota or why it didn't affect the time before Sunday. Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Monday, March 11, 2013 11:49 AM To: arslist@ARSLIST.ORG Subject: EXTERNAL: Re: DST issues today My first question would be has anyone updated the Java on your server since the last time change? I think that the ARS server uses a Java routine to determine the timestamp. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Reiser, John J Sent: Monday, March 11, 2013 10:26 AM To: arslist@ARSLIST.ORG Subject: DST issues today Hello Listers, ARS 7.6.03 MS SQL 2005 MS OS Windows 2003 Enterprise Is anyone who has gone through the change to DST experiencing time stamp issues? My client machine and my server are displaying the correct Daylight Saving Time but the timestamp in the create date field on my system are still coming up as Eastern Standard Time. Haven't had an issue like this for many years now and it's kind of thrown me off. Any ideas out there? Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: DST issues today RESOLVED
Fred, They probably have. They don't inform me when they make "Security required" updates to the server. I tried a few more clients. Mid Tier via a browser running on my local PC shows the correct time. Mid Tier running a browser on the server in a Remote Desktop window shows the wrong time (Standard Time). And again, the WUT running on my PC shows the wrong time. I don't have a WUT on the server. I went to some other PC's and these folks got the correct time. I checked my Preferences and had America/Bogota in the settings which I thought would conflict with the Mid Tier. Anyway, I cleared the setting in Time settings on the WUT and everything works now. Don't know how or why the Time Zone was set to America/Bogota or why it didn't affect the time before Sunday. Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Monday, March 11, 2013 11:49 AM To: arslist@ARSLIST.ORG Subject: EXTERNAL: Re: DST issues today My first question would be has anyone updated the Java on your server since the last time change? I think that the ARS server uses a Java routine to determine the timestamp. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Reiser, John J Sent: Monday, March 11, 2013 10:26 AM To: arslist@ARSLIST.ORG Subject: DST issues today Hello Listers, ARS 7.6.03 MS SQL 2005 MS OS Windows 2003 Enterprise Is anyone who has gone through the change to DST experiencing time stamp issues? My client machine and my server are displaying the correct Daylight Saving Time but the timestamp in the create date field on my system are still coming up as Eastern Standard Time. Haven't had an issue like this for many years now and it's kind of thrown me off. Any ideas out there? Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: DST issues today
My first question would be has anyone updated the Java on your server since the last time change? I think that the ARS server uses a Java routine to determine the timestamp. Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Reiser, John J Sent: Monday, March 11, 2013 10:26 AM To: arslist@ARSLIST.ORG Subject: DST issues today Hello Listers, ARS 7.6.03 MS SQL 2005 MS OS Windows 2003 Enterprise Is anyone who has gone through the change to DST experiencing time stamp issues? My client machine and my server are displaying the correct Daylight Saving Time but the timestamp in the create date field on my system are still coming up as Eastern Standard Time. Haven't had an issue like this for many years now and it's kind of thrown me off. Any ideas out there? Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
DST issues today
Hello Listers, ARS 7.6.03 MS SQL 2005 MS OS Windows 2003 Enterprise Is anyone who has gone through the change to DST experiencing time stamp issues? My client machine and my server are displaying the correct Daylight Saving Time but the timestamp in the create date field on my system are still coming up as Eastern Standard Time. Haven't had an issue like this for many years now and it's kind of thrown me off. Any ideas out there? Thank you, --- John J. Reiser Remedy Developer/Administrator Senior Software Development Analyst Lockheed Martin - MS2 The star that burns twice as bright burns half as long. Pay close attention and be illuminated by its brilliance. - paraphrased by me ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: SLA Targets and Daylight Saving Time (DST)
Thanks very much for the info. In this instance there is 1 business entity per SLA, and 1 SLA for each country. Each business entity contains 2 time segments, 1 for office hours, and 1 for holidays (Available & Unavailable). Both entities use the same timezone for that region. This is where I lose the plot. there are only a limited number of timezones in the time segment drop down. 1. Does anyone know if this covers Daylight Savings for each & every country? 2. How can I be sure I have chosen the correct timezone for a specific country? Is there a list somewhere showing which timezone should be used for which country? A country list showing GMT/UTC is available from a search engine, but there seems no way to map these back to Remedy timezone values in many cases. If someone could answer these questions, then the full understanding will be complete! Mike On Thu, Sep 13, 2012 at 8:59 PM, Goodall, Andrew C wrote: > ** > > I believe that the calculations are done by the business rules engine, > i.e. slmbrsvc.exe on windows > > > > The business rules engine runs on the server, so it uses the DST logic on > the server whether unix or windows, so as long as your server is patched > and up to date with latest OS patches then you should be good to go. > > > > The SLA just needs to contain the appropriate business entity in “Goals > and Cost” à Business schedule, and it is here you could have the problem. > > > > If you have one SLA but multiple business entities then you can’t hard > code the entity in the SLA it needs to be dynamic value “use on App Form” > à see App Admin Console à Service Level Management à Data Sources > àMSP/Business Time > à Fields For Business Time. Otherwise you would need an SLA per business > entity if you’re going to hardcode it. > > > > Regards, > > > > *Andrew C. Goodall* > > Software Engineer > > Development Services > > ago...@jcpenney.com > > *jcpenney* > > 6501 Legacy Drive > > Plano, TX 75024 > > jcp.com > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@arslist.org] *On Behalf Of *Mike Buck > *Sent:* Thursday, September 13, 2012 2:42 PM > *To:* arslist@arslist.org > *Subject:* SLA Targets and Daylight Saving Time (DST) > > > > ** > > Hi All > > > > I am hoping there are some experts out there who are familiar with how > this is implemented (ITSM 7.6.04). > > > > As we know building an SLA requires the need for Time Segments: Available > (office hours) & Unavailable (holidays). Time Zone (i.e. GMT+2) is set in > the Time Segment for the Requesters Country in question. > > > > Time Segments are then association with a Business Entity, and the > Business Entity is finally associated with the SLA. > > > > > > These are some of my questions: > > > > 1. How does Remedy take care of DST in specific countries? > > > > 2. How does it know, assuming it does know, which DST offset to apply and > when? > > > > 3. Does anything need to be configured for DST so that it gets applied to > the SLA Target? > > > > Thanks very much > > > > Mike > > > > > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > > The information transmitted is intended only for the person or entity to > which it is addressed and > may contain confidential and/or privileged material. If the reader of this > message is not the intended > recipient, you are hereby notified that your access is unauthorized, and > any review, dissemination, > distribution or copying of this message including any attachments is > strictly prohibited. If you are not > the intended recipient, please contact the sender and delete the material > from any computer. > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: SLA Targets and Daylight Saving Time (DST)
I believe that the calculations are done by the business rules engine, i.e. slmbrsvc.exe on windows The business rules engine runs on the server, so it uses the DST logic on the server whether unix or windows, so as long as your server is patched and up to date with latest OS patches then you should be good to go. The SLA just needs to contain the appropriate business entity in "Goals and Cost" à Business schedule, and it is here you could have the problem. If you have one SLA but multiple business entities then you can't hard code the entity in the SLA it needs to be dynamic value "use on App Form" à see App Admin Console à Service Level Management à Data Sources à MSP/Business Time à Fields For Business Time. Otherwise you would need an SLA per business entity if you're going to hardcode it. Regards, Andrew C. Goodall Software Engineer Development Services ago...@jcpenney.com jcpenney 6501 Legacy Drive Plano, TX 75024 jcp.com From: Action Request System discussion list(ARSList) [mailto:arslist@arslist.org] On Behalf Of Mike Buck Sent: Thursday, September 13, 2012 2:42 PM To: arslist@arslist.org Subject: SLA Targets and Daylight Saving Time (DST) ** Hi All I am hoping there are some experts out there who are familiar with how this is implemented (ITSM 7.6.04). As we know building an SLA requires the need for Time Segments: Available (office hours) & Unavailable (holidays). Time Zone (i.e. GMT+2) is set in the Time Segment for the Requesters Country in question. Time Segments are then association with a Business Entity, and the Business Entity is finally associated with the SLA. These are some of my questions: 1. How does Remedy take care of DST in specific countries? 2. How does it know, assuming it does know, which DST offset to apply and when? 3. Does anything need to be configured for DST so that it gets applied to the SLA Target? Thanks very much Mike _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If the reader of this message is not the intendedrecipient, you are hereby notified that your access is unauthorized, and any review, dissemination,distribution or copying of this message including any attachments is strictly prohibited. If you are notthe intended recipient, please contact the sender and delete the material from any computer. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
SLA Targets and Daylight Saving Time (DST)
Hi All I am hoping there are some experts out there who are familiar with how this is implemented (ITSM 7.6.04). As we know building an SLA requires the need for Time Segments: Available (office hours) & Unavailable (holidays). Time Zone (i.e. GMT+2) is set in the Time Segment for the Requesters Country in question. Time Segments are then association with a Business Entity, and the Business Entity is finally associated with the SLA. These are some of my questions: 1. How does Remedy take care of DST in specific countries? 2. How does it know, assuming it does know, which DST offset to apply and when? 3. Does anything need to be configured for DST so that it gets applied to the SLA Target? Thanks very much Mike ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Strange time display issues, possible DST bug?
So far the issue has only been seen on Windows 7 boxes. On Thu, Nov 3, 2011 at 1:46 PM, Grooms, Frederick W < frederick.w.gro...@xo.com> wrote: > Thanks for the update. Do you know if it was reproducible on XP using > the 7.6.04 SP2 User Tool (or was it a Windows 7 only issue)? > > -Original Message- > From: Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] On Behalf Of Paul Blasquez > Sent: Thursday, November 03, 2011 3:40 PM > To: arslist@ARSLIST.ORG > Subject: Re: Strange time display issues, possible DST bug? > > ** Thanks for your replies, Axton and Fred. > > BMC got back to me and we were able to demonstrate the issue to them over > a webex. BMC was able to replicate the issue in one of their test > environments and the tech is going to request a defect be issued but he > emphasized that he has no idea whether it will be patched or not due to the > EOL status of the User Client. > > Downgrading the User Client to 7.1 fixes the issue. The issue was > replicated by BMC in version 7.5 and 7.6 of the user client on Windows 7 > client machines. > > Hope this helps someone else out there. > > Thanks, > > -Paul > On Thu, Nov 3, 2011 at 12:27 PM, Grooms, Frederick W < > frederick.w.gro...@xo.com> wrote: > Do you have ALL the Windows 7 DST patches on Laptop 2? > > When does each laptop think that the DST change is set to take effect? > > Fred > > -Original Message- > From: Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] On Behalf Of Paul Blasquez > Sent: Thursday, November 03, 2011 2:08 PM > To: arslist@ARSLIST.ORG > Subject: Re: Strange time display issues, possible DST bug? > > ** Correction, we have a 7.1 patch 7 server. > > Clarification: The 1 hour discrepancy appears when displaying date/time > fields and $TIMESTAMP$ variables on forms in the user client. Sorry that > it wasn't clear in the original wording. I've corrected it in red below: > On Thu, Nov 3, 2011 at 11:44 AM, Paul Blasquez wrote: > Hello All, > > We have a very strange issue on our custom 7.1 patch 22 server and I > wanted to reach out to see if anyone else is encountering this or if they > have any insight. > > The issue is that a random sample of Windows 7 users is seeing timestamps > as 1 hour less than their configured timezone. We've been able to set up > an experiment to isolate the behavior as best as possible. > > Behavior is from two identical laptops: > > . Model: Dell Latitude E6420 > . OS: Window 7 SP1, same KBs installed. > . Remedy User Client: 7.6.04 SP2 > . We are using the same user. > . The user has their Time Zone set to GMT -8:00 America/Los > Angeles. We've used preferences both locally on each laptop and from a > preference server. > > Description of the Behavior: > > . From Laptop1 we always see the correct time on the date/time > fields. > . From Laptop 2 we always see the time as 1 hour less than the > correct time. > . This issue goes away if we set the date on Laptop 2 to be beyond > the DST change at 2am on Nov 6th. > . The issue persists if we use different timezones. > > So, if the date/time field or $TIMESTAMP$ is displayed as 5:00pm on Laptop > 1, we see 4:00pm on Laptop2. When we set the date/time on Laptop 2 to any > time after 2am on Nov 6th, this discrepancy goes away. If we change the > time zones around, the -1 hour difference follows the change. > > The evidence points to some sort of DST discrepancy and we cannot rule out > the User Client at this time. We have a ticket open with BMC but it is > still going through the support channels right now. > > Does anyone here know what time-related variables are involved with the > User Client interaction with the server, and what are the sources of those > variables? I've scoured the Windows 7 information out there looking for > all time variables and comparing them on each laptop and everything is > identical so far. > > Any information is much appreciated! > > Thanks, > > Paul Blasquez > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Strange time display issues, possible DST bug?
Thanks for the update. Do you know if it was reproducible on XP using the 7.6.04 SP2 User Tool (or was it a Windows 7 only issue)? -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Paul Blasquez Sent: Thursday, November 03, 2011 3:40 PM To: arslist@ARSLIST.ORG Subject: Re: Strange time display issues, possible DST bug? ** Thanks for your replies, Axton and Fred. BMC got back to me and we were able to demonstrate the issue to them over a webex. BMC was able to replicate the issue in one of their test environments and the tech is going to request a defect be issued but he emphasized that he has no idea whether it will be patched or not due to the EOL status of the User Client. Downgrading the User Client to 7.1 fixes the issue. The issue was replicated by BMC in version 7.5 and 7.6 of the user client on Windows 7 client machines. Hope this helps someone else out there. Thanks, -Paul On Thu, Nov 3, 2011 at 12:27 PM, Grooms, Frederick W wrote: Do you have ALL the Windows 7 DST patches on Laptop 2? When does each laptop think that the DST change is set to take effect? Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Paul Blasquez Sent: Thursday, November 03, 2011 2:08 PM To: arslist@ARSLIST.ORG Subject: Re: Strange time display issues, possible DST bug? ** Correction, we have a 7.1 patch 7 server. Clarification: The 1 hour discrepancy appears when displaying date/time fields and $TIMESTAMP$ variables on forms in the user client. Sorry that it wasn't clear in the original wording. I've corrected it in red below: On Thu, Nov 3, 2011 at 11:44 AM, Paul Blasquez wrote: Hello All, We have a very strange issue on our custom 7.1 patch 22 server and I wanted to reach out to see if anyone else is encountering this or if they have any insight. The issue is that a random sample of Windows 7 users is seeing timestamps as 1 hour less than their configured timezone. We've been able to set up an experiment to isolate the behavior as best as possible. Behavior is from two identical laptops: . Model: Dell Latitude E6420 . OS: Window 7 SP1, same KBs installed. . Remedy User Client: 7.6.04 SP2 . We are using the same user. . The user has their Time Zone set to GMT -8:00 America/Los Angeles. We've used preferences both locally on each laptop and from a preference server. Description of the Behavior: . From Laptop1 we always see the correct time on the date/time fields. . From Laptop 2 we always see the time as 1 hour less than the correct time. . This issue goes away if we set the date on Laptop 2 to be beyond the DST change at 2am on Nov 6th. . The issue persists if we use different timezones. So, if the date/time field or $TIMESTAMP$ is displayed as 5:00pm on Laptop 1, we see 4:00pm on Laptop2. When we set the date/time on Laptop 2 to any time after 2am on Nov 6th, this discrepancy goes away. If we change the time zones around, the -1 hour difference follows the change. The evidence points to some sort of DST discrepancy and we cannot rule out the User Client at this time. We have a ticket open with BMC but it is still going through the support channels right now. Does anyone here know what time-related variables are involved with the User Client interaction with the server, and what are the sources of those variables? I've scoured the Windows 7 information out there looking for all time variables and comparing them on each laptop and everything is identical so far. Any information is much appreciated! Thanks, Paul Blasquez _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Strange time display issues, possible DST bug?
Thanks for you replies, Axton and Fred. BMC got back to me and we were able to demonstrate the issue to them over a webex. BMC was able to replicate the issue in one of their test environments and the tech is going to request a defect be issued but he emphasized that he has no idea whether it will be patched or not due to the EOL status of the User Client. Downgrading the User Client to 7.1 fixes the issue. The issue was replicated by BMC in version 7.5 and 7.6 of the user client on Windows 7 client machines. Hope this helps someone else out there. Thanks, -Paul On Thu, Nov 3, 2011 at 12:27 PM, Grooms, Frederick W < frederick.w.gro...@xo.com> wrote: > Do you have ALL the Windows 7 DST patches on Laptop 2? > > When does each laptop think that the DST change is set to take effect? > > Fred > > -Original Message- > From: Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] On Behalf Of Paul Blasquez > Sent: Thursday, November 03, 2011 2:08 PM > To: arslist@ARSLIST.ORG > Subject: Re: Strange time display issues, possible DST bug? > > ** Correction, we have a 7.1 patch 7 server. > > Clarification: The 1 hour discrepancy appears when displaying date/time > fields and $TIMESTAMP$ variables on forms in the user client. Sorry that > it wasn't clear in the original wording. I've corrected it in red below: > On Thu, Nov 3, 2011 at 11:44 AM, Paul Blasquez wrote: > Hello All, > > We have a very strange issue on our custom 7.1 patch 22 server and I > wanted to reach out to see if anyone else is encountering this or if they > have any insight. > > The issue is that a random sample of Windows 7 users is seeing timestamps > as 1 hour less than their configured timezone. We've been able to set up > an experiment to isolate the behavior as best as possible. > > Behavior is from two identical laptops: > > . Model: Dell Latitude E6420 > . OS: Window 7 SP1, same KBs installed. > . Remedy User Client: 7.6.04 SP2 > . We are using the same user. > . The user has their Time Zone set to GMT -8:00 America/Los > Angeles. We've used preferences both locally on each laptop and from a > preference server. > > Description of the Behavior: > > . From Laptop1 we always see the correct time on the date/time > fields. > . From Laptop 2 we always see the time as 1 hour less than the > correct time. > . This issue goes away if we set the date on Laptop 2 to be beyond > the DST change at 2am on Nov 6th. > . The issue persists if we use different timezones. > > So, if the date/time field or $TIMESTAMP$ is displayed as 5:00pm on Laptop > 1, we see 4:00pm on Laptop2. When we set the date/time on Laptop 2 to any > time after 2am on Nov 6th, this discrepancy goes away. If we change the > time zones around, the -1 hour difference follows the change. > > The evidence points to some sort of DST discrepancy and we cannot rule out > the User Client at this time. We have a ticket open with BMC but it is > still going through the support channels right now. > > Does anyone here know what time-related variables are involved with the > User Client interaction with the server, and what are the sources of those > variables? I've scoured the Windows 7 information out there looking for > all time variables and comparing them on each laptop and everything is > identical so far. > > Any information is much appreciated! > > Thanks, > > Paul Blasquez > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > > > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are" > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Strange time display issues, possible DST bug?
Do you have ALL the Windows 7 DST patches on Laptop 2? When does each laptop think that the DST change is set to take effect? Fred -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Paul Blasquez Sent: Thursday, November 03, 2011 2:08 PM To: arslist@ARSLIST.ORG Subject: Re: Strange time display issues, possible DST bug? ** Correction, we have a 7.1 patch 7 server. Clarification: The 1 hour discrepancy appears when displaying date/time fields and $TIMESTAMP$ variables on forms in the user client. Sorry that it wasn't clear in the original wording. I've corrected it in red below: On Thu, Nov 3, 2011 at 11:44 AM, Paul Blasquez wrote: Hello All, We have a very strange issue on our custom 7.1 patch 22 server and I wanted to reach out to see if anyone else is encountering this or if they have any insight. The issue is that a random sample of Windows 7 users is seeing timestamps as 1 hour less than their configured timezone. We've been able to set up an experiment to isolate the behavior as best as possible. Behavior is from two identical laptops: . Model: Dell Latitude E6420 . OS: Window 7 SP1, same KBs installed. . Remedy User Client: 7.6.04 SP2 . We are using the same user. . The user has their Time Zone set to GMT -8:00 America/Los Angeles. We've used preferences both locally on each laptop and from a preference server. Description of the Behavior: . From Laptop1 we always see the correct time on the date/time fields. . From Laptop 2 we always see the time as 1 hour less than the correct time. . This issue goes away if we set the date on Laptop 2 to be beyond the DST change at 2am on Nov 6th. . The issue persists if we use different timezones. So, if the date/time field or $TIMESTAMP$ is displayed as 5:00pm on Laptop 1, we see 4:00pm on Laptop2. When we set the date/time on Laptop 2 to any time after 2am on Nov 6th, this discrepancy goes away. If we change the time zones around, the -1 hour difference follows the change. The evidence points to some sort of DST discrepancy and we cannot rule out the User Client at this time. We have a ticket open with BMC but it is still going through the support channels right now. Does anyone here know what time-related variables are involved with the User Client interaction with the server, and what are the sources of those variables? I've scoured the Windows 7 information out there looking for all time variables and comparing them on each laptop and everything is identical so far. Any information is much appreciated! Thanks, Paul Blasquez _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Strange time display issues, possible DST bug?
Timezone information is extrapolated from the client machine using javascript. There is no other way to get this information. Check the settings on the client machine; make sure both the date/time and timezone information is accurate. Also check the version of java in use with your midtier. Java is used to perform the translation, in part, and the date is important for the DST/non-DST times. See this reference for the JRE version/timezone table in use: http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html Also, there is a chance that the js files included with the midtier do not have accurate data on which to act. There are a bunch of TZ javascript files that come into play here. I don't remember seeing anything in relation to changes here in the release notes, but it would make sense that those have to be up to date. If these things are all set properly, then things should just work. These things are the glue that make all this work. Writing all this from memory, so corrections are welcomed. Axton Grams On Thu, Nov 3, 2011 at 1:44 PM, Paul Blasquez wrote: > ** > > Hello All, > > > > We have a very strange issue on our custom 7.1 patch 22 server and I > wanted to reach out to see if anyone else is encountering this or if they > have any insight. > > > > The issue is that a random sample of Windows 7 users is seeing timestamps > as 1 hour less than their configured timezone. We’ve been able to set up > an experiment to isolate the behavior as best as possible. > > > > Behavior is from two identical laptops: > > > > · Model: Dell Latitude E6420 > > · OS: Window 7 SP1, same KBs installed. > > · Remedy User Client: 7.6.04 SP2 > > · We are using the same user. > > · The user has their Time Zone set to GMT -8:00 America/Los > Angeles. We've used preferences both locally on each laptop and from a > preference server. > > > > Description of the Behavior: > > > > · From Laptop1 we always see the correct time on the date/time > fields. > > · From Laptop 2 we always see the time as 1 hour less than the > correct time. > > · This issue goes away if we set the date on Laptop 2 to be > beyond the DST change at 2am on Nov 6th. > > · The issue persists if we use different timezones. > > > > So, if the time is 5:00pm, we see that correctly on Laptop 1 but we see > 4:00pm on Laptop2. When we set the date/time on Laptop 2 to any time > after 2am on Nov 6th, this discrepancy goes away. If we change the time > zones around, the -1 hour difference follows the change. > > > > The evidence points to some sort of DST discrepancy and we cannot rule out > the User Client at this time. We have a ticket open with BMC but it is > still going through the support channels right now. > > > > Does anyone here know what time-related variables are involved with the > User Client interaction with the server, and what are the sources of those > variables? I’ve scoured the Windows 7 information out there looking for > all time variables and comparing them on each laptop and everything is > identical so far. > > > > Any information is much appreciated! > > > > Thanks, > > > > Paul Blasquez > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: Strange time display issues, possible DST bug?
Correction, we have a 7.1 patch 7 server. Clarification: The 1 hour discrepancy appears when displaying date/time fields and $TIMESTAMP$ variables on forms in the user client. Sorry that it wasn't clear in the original wording. I've corrected it in red below: On Thu, Nov 3, 2011 at 11:44 AM, Paul Blasquez wrote: > Hello All, > > > > We have a very strange issue on our custom 7.1 patch 22 server and I > wanted to reach out to see if anyone else is encountering this or if they > have any insight. > > > > The issue is that a random sample of Windows 7 users is seeing timestamps > as 1 hour less than their configured timezone. We’ve been able to set up > an experiment to isolate the behavior as best as possible. > > > > Behavior is from two identical laptops: > > > > · Model: Dell Latitude E6420 > > · OS: Window 7 SP1, same KBs installed. > > · Remedy User Client: 7.6.04 SP2 > > · We are using the same user. > > · The user has their Time Zone set to GMT -8:00 America/Los > Angeles. We've used preferences both locally on each laptop and from a > preference server. > > > > Description of the Behavior: > > > > · From Laptop1 we always see the correct time on the date/time > fields. > > · From Laptop 2 we always see the time as 1 hour less than the > correct time. > > · This issue goes away if we set the date on Laptop 2 to be > beyond the DST change at 2am on Nov 6th. > > · The issue persists if we use different timezones. > > > > So, if the date/time field or $TIMESTAMP$ is displayed as 5:00pm on Laptop > 1, we see 4:00pm on Laptop2. When we set the date/time on Laptop 2 to > any time after 2am on Nov 6th, this discrepancy goes away. If we change > the time zones around, the -1 hour difference follows the change. > > > > The evidence points to some sort of DST discrepancy and we cannot rule out > the User Client at this time. We have a ticket open with BMC but it is > still going through the support channels right now. > > > > Does anyone here know what time-related variables are involved with the > User Client interaction with the server, and what are the sources of those > variables? I’ve scoured the Windows 7 information out there looking for > all time variables and comparing them on each laptop and everything is > identical so far. > > > > Any information is much appreciated! > > > > Thanks, > > > > Paul Blasquez > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Strange time display issues, possible DST bug?
Hello All, We have a very strange issue on our custom 7.1 patch 22 server and I wanted to reach out to see if anyone else is encountering this or if they have any insight. The issue is that a random sample of Windows 7 users is seeing timestamps as 1 hour less than their configured timezone. We’ve been able to set up an experiment to isolate the behavior as best as possible. Behavior is from two identical laptops: · Model: Dell Latitude E6420 · OS: Window 7 SP1, same KBs installed. · Remedy User Client: 7.6.04 SP2 · We are using the same user. · The user has their Time Zone set to GMT -8:00 America/Los Angeles. We've used preferences both locally on each laptop and from a preference server. Description of the Behavior: · From Laptop1 we always see the correct time on the date/time fields. · From Laptop 2 we always see the time as 1 hour less than the correct time. · This issue goes away if we set the date on Laptop 2 to be beyond the DST change at 2am on Nov 6th. · The issue persists if we use different timezones. So, if the time is 5:00pm, we see that correctly on Laptop 1 but we see 4:00pm on Laptop2. When we set the date/time on Laptop 2 to any time after 2am on Nov 6th, this discrepancy goes away. If we change the time zones around, the -1 hour difference follows the change. The evidence points to some sort of DST discrepancy and we cannot rule out the User Client at this time. We have a ticket open with BMC but it is still going through the support channels right now. Does anyone here know what time-related variables are involved with the User Client interaction with the server, and what are the sources of those variables? I’ve scoured the Windows 7 information out there looking for all time variables and comparing them on each laptop and everything is identical so far. Any information is much appreciated! Thanks, Paul Blasquez ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
Re: DST and Escalations
John, As others have mentioned…it is obviously because of the DST switch…but in this case what happens is that the system doesn’t keep track of ‘when’ to fire the escalation next…it keeps track of how many seconds till that escalation should fire again….so in this case it ran at 1PM and set it to run again in 86400 seconds….the next day you ran the 1AM hour twice, so you found that in that particular day there were an hour more seconds in the day…so 86400 seconds AFTER it ran last was actually Noon, not 1…. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of J Kovalcik Sent: Tuesday, November 16, 2010 1:20 PM To: arslist@ARSLIST.ORG Subject: DST and Escalations ** Listers, Just wanted to see if anyone is having these same issues. We have a Time escalation that runs every weekday at 1:00pm. This past week the escalation ran at 12:00 noon on Monday right after DST had changed. The next occurrence it ran at the proper time of 1:00pm. Any help would be appreciated. Thanks, John Kovalcik _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: DST and Escalations
Hi John To avoid these sort of issues with DST you should not schedule time sensitive escalations between 12 midnight and 2 AM. What actually happens in the Fall is that the time goes to 1 AM, then changes back to 12 midnight. So, Remedy's behavior was correct - it fired at 1 AM, then fired again at 1 AM - there were 2 x 1 AMs that day. Looking back from after the DST change, the first 1AM 'looks' like 12 midnight, but at the time it occurred it was 1 AM. To avoid this you need to schedule your escalation to run after 1 AM, for example 1:07 AM. There will never be more than one of those. but there could be none - see below. In the spring, the clocks go to 1AM, then jump to 2AM, so any escalations scheduled between 1 and 2 AM will be skipped. The solution is to schedule your escalations to occur before midnight or after 2 AM if this is a concern to you. That way there will always only be one occurrence per day. HTH David Sanders Solution Architect Enterprise Service Suite @ Work / e-ServiceSuite tel +44 1494 468980 mobile +44 7710 377761 email david.sand...@westoverconsulting.co.uk web http://www.westoverconsulting.co.uk <http://www.westoverconsulting.co.uk/> http://www.e-servicesuite.co.uk <http://www.e-servicesuite.co.uk/> <http://e-servicesuite.com/> ITIL - SaaS - On Premise _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of J Kovalcik Sent: Tuesday, November 16, 2010 8:20 PM To: arslist@ARSLIST.ORG Subject: DST and Escalations Listers, Just wanted to see if anyone is having these same issues. We have a Time escalation that runs every weekday at 1:00pm. This past week the escalation ran at 12:00 noon on Monday right after DST had changed. The next occurrence it ran at the proper time of 1:00pm. Any help would be appreciated. Thanks, John Kovalcik _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" <>
Re: DST and Escalations
** We always cycle the AR System services after the time changes. It eliminates any issues caused by the change to/from DST. Dave - dave.shell...@tycoelectronics.com (Wireless) From: Action Request System discussion list(ARSList) To: arslist@ARSLIST.ORG Sent: Tue Nov 16 15:20:15 2010 Subject: DST and Escalations Listers, Just wanted to see if anyone is having these same issues. We have a Time escalation that runs every weekday at 1:00pm. This past week the escalation ran at 12:00 noon on Monday right after DST had changed. The next occurrence it ran at the proper time of 1:00pm. Any help would be appreciated. Thanks, John Kovalcik _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_
DST and Escalations
Listers, Just wanted to see if anyone is having these same issues. We have a Time escalation that runs every weekday at 1:00pm. This past week the escalation ran at 12:00 noon on Monday right after DST had changed. The next occurrence it ran at the proper time of 1:00pm. Any help would be appreciated. Thanks, John Kovalcik ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
Re: Weird DST date calculation issue - RESOLVED
Lucky for you this worked. It doesn't work for me because I need to keep the
time the same. (If someone wanted 3.15.2010 at 6:00pm, it has to stay that way)
The DATEADD Function is great, but it resets the time back to 12:00:00 AM.
I actually had to parse the data, set aside the time, add the days and then put
it all back together again in the end. Works well, but I hate all the extra
workflow.
Lisa
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Charles Baldi
Sent: Thursday, March 04, 2010 10:45 AM
To: arslist@ARSLIST.ORG
Subject: Re: Weird DST date calculation issue - RESOLVED
Glad to hear it. Yeah, I meant to say "day" but we use "month" here so...
Regards,
Chuck
On Thu, Mar 4, 2010 at 10:05 AM, William Rentfrow
wrote:
> The suggestion below actually worked - except I changed it to this:
>
> DATEADD("day",-10,$My Date$)
>
> William Rentfrow
> Principal Consultant, StrataCom Inc.
> wrentf...@stratacominc.com
> Blog: www.williamrentfrow.com
> O 715-592-5185
> C 715-410-8056
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:arsl...@arslist.org] On Behalf Of Charles Baldi
> Sent: Tuesday, March 02, 2010 11:14 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Weird DST date calculation issue
>
> William,
> If you use the dateadd() function do you get a different result?
> E.g.,
>
> dateadd("month", -10, date($My Date$))
>
> Regards,
> Chuck Baldi
>
> On Tue, Mar 2, 2010 at 12:02 PM, William Rentfrow
> wrote:
>> **
>>
>> Fortunately this issue SHOULD be very straight forward.
>>
>> Unfortunately - it isn't.
>>
>> There's a button that calculates a person's period of eligibility to
>> make changes to their HR benefits, etc. You enter their employment
>> anniversary date and hit the button and this performs a calculation:
>>
>> $My Date$ - 864000 (i.e., minus 10 days).
>>
>> Here's the interesting thing - when the date entered is Daylight
>> savings time - 3/15 this spring - the calculated value for the date
>> time field returns 3/4/2010 11:00:00 PM. Normally all of the times
>> in this date/time field are left at 12:00:00 AM and are unused.
>>
>> Technically speaking the calculation is EXACTLY correct. 3/4/2010
>> 11:00:00 PM is exactly 10 days before 3/15/2010 12:00:00 AM - because
>> 3/15 has an "extra" hour added that is a figment of our collective
>> imagination.
>> Technically DST doesn't happen until 2:00 AM though but that's a
>> matter for another time.
>>
>> I was thinking about changing the times on these to default to
>> 3:00:00 AM instead of 12:00:00 AM - but I'm open to suggestions.
>>
>> William Rentfrow
>> Principal Consultant, StrataCom Inc.
>> wrentf...@stratacominc.com
>> Blog: www.williamrentfrow.com
>> O 715-592-5185
>> C 715-410-8056
>>
>> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the
>> Answers Are"_
>
> __
> _ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
>
> __
> _ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
>
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
Re: Weird DST date calculation issue - RESOLVED
Glad to hear it. Yeah, I meant to say "day" but we use "month" here so...
Regards,
Chuck
On Thu, Mar 4, 2010 at 10:05 AM, William Rentfrow
wrote:
> The suggestion below actually worked - except I changed it to this:
>
> DATEADD("day",-10,$My Date$)
>
> William Rentfrow
> Principal Consultant, StrataCom Inc.
> wrentf...@stratacominc.com
> Blog: www.williamrentfrow.com
> O 715-592-5185
> C 715-410-8056
>
> -Original Message-
> From: Action Request System discussion list(ARSList)
> [mailto:arsl...@arslist.org] On Behalf Of Charles Baldi
> Sent: Tuesday, March 02, 2010 11:14 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: Weird DST date calculation issue
>
> William,
> If you use the dateadd() function do you get a different result? E.g.,
>
> dateadd("month", -10, date($My Date$))
>
> Regards,
> Chuck Baldi
>
> On Tue, Mar 2, 2010 at 12:02 PM, William Rentfrow
> wrote:
>> **
>>
>> Fortunately this issue SHOULD be very straight forward.
>>
>> Unfortunately - it isn't.
>>
>> There's a button that calculates a person's period of eligibility to
>> make changes to their HR benefits, etc. You enter their employment
>> anniversary date and hit the button and this performs a calculation:
>>
>> $My Date$ - 864000 (i.e., minus 10 days).
>>
>> Here's the interesting thing - when the date entered is Daylight
>> savings time - 3/15 this spring - the calculated value for the date
>> time field returns 3/4/2010 11:00:00 PM. Normally all of the times in
>> this date/time field are left at 12:00:00 AM and are unused.
>>
>> Technically speaking the calculation is EXACTLY correct. 3/4/2010
>> 11:00:00 PM is exactly 10 days before 3/15/2010 12:00:00 AM - because
>> 3/15 has an "extra" hour added that is a figment of our collective
>> imagination.
>> Technically DST doesn't happen until 2:00 AM though but that's a
>> matter for another time.
>>
>> I was thinking about changing the times on these to default to 3:00:00
>> AM instead of 12:00:00 AM - but I'm open to suggestions.
>>
>> William Rentfrow
>> Principal Consultant, StrataCom Inc.
>> wrentf...@stratacominc.com
>> Blog: www.williamrentfrow.com
>> O 715-592-5185
>> C 715-410-8056
>>
>> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the
>> Answers Are"_
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
> Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
>
> ___
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
>
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
Re: Weird DST date calculation issue - RESOLVED
The suggestion below actually worked - except I changed it to this:
DATEADD("day",-10,$My Date$)
William Rentfrow
Principal Consultant, StrataCom Inc.
wrentf...@stratacominc.com
Blog: www.williamrentfrow.com
O 715-592-5185
C 715-410-8056
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Charles Baldi
Sent: Tuesday, March 02, 2010 11:14 AM
To: arslist@ARSLIST.ORG
Subject: Re: Weird DST date calculation issue
William,
If you use the dateadd() function do you get a different result? E.g.,
dateadd("month", -10, date($My Date$))
Regards,
Chuck Baldi
On Tue, Mar 2, 2010 at 12:02 PM, William Rentfrow
wrote:
> **
>
> Fortunately this issue SHOULD be very straight forward.
>
> Unfortunately - it isn't.
>
> There's a button that calculates a person's period of eligibility to
> make changes to their HR benefits, etc. You enter their employment
> anniversary date and hit the button and this performs a calculation:
>
> $My Date$ - 864000 (i.e., minus 10 days).
>
> Here's the interesting thing - when the date entered is Daylight
> savings time - 3/15 this spring - the calculated value for the date
> time field returns 3/4/2010 11:00:00 PM. Normally all of the times in
> this date/time field are left at 12:00:00 AM and are unused.
>
> Technically speaking the calculation is EXACTLY correct. 3/4/2010
> 11:00:00 PM is exactly 10 days before 3/15/2010 12:00:00 AM - because
> 3/15 has an "extra" hour added that is a figment of our collective
> imagination.
> Technically DST doesn't happen until 2:00 AM though but that's a
> matter for another time.
>
> I was thinking about changing the times on these to default to 3:00:00
> AM instead of 12:00:00 AM - but I'm open to suggestions.
>
> William Rentfrow
> Principal Consultant, StrataCom Inc.
> wrentf...@stratacominc.com
> Blog: www.williamrentfrow.com
> O 715-592-5185
> C 715-410-8056
>
> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the
> Answers Are"_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
Re: Weird DST date calculation issue
Bill, It's taken me a long time to understand this issue. Still haven't figured out a good solution. The effect is because of the observance of DST when it changes. The issue is that you are subtracting a constant from the date. Where DST is observed, 2 days out of the year are not 24 hours. In the statements below I will reference dates in the US but the concept is the same for any where that observes DST. March 14th is a short day. That day is 23 hours in length. So 864000 is not exactly 10 days during that time period. 864000 translates to 10 days and 1 hour until after march 15th in your case. On November 7th this year you have the opposite effect. November 7th is a 25 hour day. 864000 would translate to 9 days and 23 hours until after November 17th. Hope this helps with the understanding of what is happening. Dave From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of William Rentfrow Sent: Tuesday, March 02, 2010 12:03 PM To: arslist@ARSLIST.ORG Subject: Weird DST date calculation issue ** Fortunately this issue SHOULD be very straight forward. Unfortunately - it isn't. There's a button that calculates a person's period of eligibility to make changes to their HR benefits, etc. You enter their employment anniversary date and hit the button and this performs a calculation: $My Date$ - 864000 (i.e., minus 10 days). Here's the interesting thing - when the date entered is Daylight savings time - 3/15 this spring - the calculated value for the date time field returns 3/4/2010 11:00:00 PM. Normally all of the times in this date/time field are left at 12:00:00 AM and are unused. Technically speaking the calculation is EXACTLY correct. 3/4/2010 11:00:00 PM is exactly 10 days before 3/15/2010 12:00:00 AM - because 3/15 has an "extra" hour added that is a figment of our collective imagination. Technically DST doesn't happen until 2:00 AM though but that's a matter for another time. I was thinking about changing the times on these to default to 3:00:00 AM instead of 12:00:00 AM - but I'm open to suggestions. William Rentfrow Principal Consultant, StrataCom Inc. wrentf...@stratacominc.com Blog: www.williamrentfrow.com O 715-592-5185 C 715-410-8056 _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
Re: Weird DST date calculation issue
William,
If you use the dateadd() function do you get a different result? E.g.,
dateadd("month", -10, date($My Date$))
Regards,
Chuck Baldi
On Tue, Mar 2, 2010 at 12:02 PM, William Rentfrow
wrote:
> **
>
> Fortunately this issue SHOULD be very straight forward.
>
> Unfortunately - it isn't.
>
> There's a button that calculates a person's period of eligibility to make
> changes to their HR benefits, etc. You enter their employment anniversary
> date and hit the button and this performs a calculation:
>
> $My Date$ - 864000 (i.e., minus 10 days).
>
> Here's the interesting thing - when the date entered is Daylight savings
> time - 3/15 this spring - the calculated value for the date time field
> returns 3/4/2010 11:00:00 PM. Normally all of the times in this date/time
> field are left at 12:00:00 AM and are unused.
>
> Technically speaking the calculation is EXACTLY correct. 3/4/2010 11:00:00
> PM is exactly 10 days before 3/15/2010 12:00:00 AM - because 3/15 has an
> "extra" hour added that is a figment of our collective imagination.
> Technically DST doesn't happen until 2:00 AM though but that's a matter for
> another time.
>
> I was thinking about changing the times on these to default to 3:00:00 AM
> instead of 12:00:00 AM - but I'm open to suggestions.
>
> William Rentfrow
> Principal Consultant, StrataCom Inc.
> wrentf...@stratacominc.com
> Blog: www.williamrentfrow.com
> O 715-592-5185
> C 715-410-8056
>
> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers
> Are"_
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
Re: Weird DST date calculation issue
** Bill,Make it 3:01 AM, just in case. :-)Or, make it do DATE(new time + 3601), which will round to the most recent midnight your newly calculated time in the case where ten days later is at 11:00 PM and the DATE () function would round to the wrong midnight.DougOn Mar 2, 2010, at 11:02 AM, William Rentfrow wrote:** Fortunately this issue SHOULD be very straight forward. Unfortunately - it isn't. There's a button that calculates a person's period of eligibility to make changes to their HR benefits, etc. You enter their employment anniversary date and hit the button and this performs a calculation:$My Date$ - 864000 (i.e., minus 10 days). Here's the interesting thing - when the date entered is Daylight savings time - 3/15 this spring - the calculated value for the date time field returns 3/4/2010 11:00:00 PM. Normally all of the times in this date/time field are left at 12:00:00 AM and are unused.Technically speaking the calculation is EXACTLY correct. 3/4/2010 11:00:00 PM is exactly 10 days before 3/15/2010 12:00:00 AM - because 3/15 has an "extra" hour added that is a figment of our collective imagination. Technically DST doesn't happen until 2:00 AM though but that's a matter for another time.I was thinking about changing the times on these to default to 3:00:00 AM instead of 12:00:00 AM - but I'm open to suggestions.William Rentfrow Principal Consultant, StrataCom Inc. wrentf...@stratacominc.com Blog: www.williamrentfrow.com O 715-592-5185 C 715-410-8056 _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ Doug--Doug Blaird...@blairing.com+1 224-558-5462200 North Arlington Heights RoadArlington Heights, Illinois 60004 _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_
Weird DST date calculation issue
Fortunately this issue SHOULD be very straight forward. Unfortunately - it isn't. There's a button that calculates a person's period of eligibility to make changes to their HR benefits, etc. You enter their employment anniversary date and hit the button and this performs a calculation: $My Date$ - 864000 (i.e., minus 10 days). Here's the interesting thing - when the date entered is Daylight savings time - 3/15 this spring - the calculated value for the date time field returns 3/4/2010 11:00:00 PM. Normally all of the times in this date/time field are left at 12:00:00 AM and are unused. Technically speaking the calculation is EXACTLY correct. 3/4/2010 11:00:00 PM is exactly 10 days before 3/15/2010 12:00:00 AM - because 3/15 has an "extra" hour added that is a figment of our collective imagination. Technically DST doesn't happen until 2:00 AM though but that's a matter for another time. I was thinking about changing the times on these to default to 3:00:00 AM instead of 12:00:00 AM - but I'm open to suggestions. William Rentfrow Principal Consultant, StrataCom Inc. wrentf...@stratacominc.com Blog: www.williamrentfrow.com O 715-592-5185 C 715-410-8056 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
Re: DST Issues
Testing Lisa -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Kemes, Lisa Sent: Tuesday, January 12, 2010 2:51 PM To: arslist@ARSLIST.ORG Subject: Re: DST Issues This topic seemed to go cold (br!) 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:arsl...@arslist.org] On Behalf Of Shellman, David Sent: Monday, January 11, 2010 1:21 PM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of Grooms, Frederick W Sent: Monday, January 11, 2010 12:20 PM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of Kemes, Lisa Sent: Monday, January 11, 2010 9:32 AM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of David Sanders Sent: Friday, January 08, 2010 10:20 AM To: arslist@ARSLIST.ORG 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 Davi
Re: DST Issues
This topic seemed to go cold (br!) 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:arsl...@arslist.org] On Behalf Of Shellman, David Sent: Monday, January 11, 2010 1:21 PM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of Grooms, Frederick W Sent: Monday, January 11, 2010 12:20 PM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of Kemes, Lisa Sent: Monday, January 11, 2010 9:32 AM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of David Sanders Sent: Friday, January 08, 2010 10:20 AM To: arslist@ARSLIST.ORG 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 david.sand...@westoverconsulting.co.uk web http://www.westoverconsulting.co.uk -Origina
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:arsl...@arslist.org] On Behalf Of Grooms, Frederick W Sent: Monday, January 11, 2010 12:20 PM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of Kemes, Lisa Sent: Monday, January 11, 2010 9:32 AM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of David Sanders Sent: Friday, January 08, 2010 10:20 AM To: arslist@ARSLIST.ORG 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 david.sand...@westoverconsulting.co.uk web http://www.westoverconsulting.co.uk -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of lisakemes Sent: 07 January 2010 21:55 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
Re: DST Issues
Nothing changes. I changed my PC to 3/15/2010 but my time did not automatically change. I still see 1:00:00 AM as the times for the records that were calculated and 12:00:00 AM on the records that were manually input on my User Client. Then I changed my PC to 3/15/2010 and manually changed my time forward an hour and I see the same thing. I'm trying to find a DST White Paper out there to help me understand what is supposed to happen. I see the Tech Bulletins (about New Zealand Time Zones and what happens to dates before 2007) but no white paper. Lisa -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Grooms, Frederick W Sent: Monday, January 11, 2010 12:20 PM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of Kemes, Lisa Sent: Monday, January 11, 2010 9:32 AM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of David Sanders Sent: Friday, January 08, 2010 10:20 AM To: arslist@ARSLIST.ORG 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 david.sand...@westoverconsulting.co.uk web http://www.westoverconsulting.co.uk -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of lisakemes Sent: 07 January 2010 21:55 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
Re: DST Issues
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 add off 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:arsl...@arslist.org] On Behalf Of Grooms, Frederick W Sent: Monday, January 11, 2010 12:20 PM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of Kemes, Lisa Sent: Monday, January 11, 2010 9:32 AM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of David Sanders Sent: Friday, January 08, 2010 10:20 AM To: arslist@ARSLIST.ORG 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 david.sand...@westoverconsulting.co.uk web http://www.westoverconsulting.co.uk -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of lisakemes Sent: 07 January 2010 21:55 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&#
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:arsl...@arslist.org] On Behalf Of Kemes, Lisa Sent: Monday, January 11, 2010 9:32 AM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org] On Behalf Of David Sanders Sent: Friday, January 08, 2010 10:20 AM To: arslist@ARSLIST.ORG 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 david.sand...@westoverconsulting.co.uk web http://www.westoverconsulting.co.uk -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of lisakemes Sent: 07 January 2010 21:55 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! ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
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:arsl...@arslist.org] On Behalf Of David Sanders Sent: Friday, January 08, 2010 10:20 AM To: arslist@ARSLIST.ORG 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 david.sand...@westoverconsulting.co.uk web http://www.westoverconsulting.co.uk -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of lisakemes Sent: 07 January 2010 21:55 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! --- ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
Re: DST Issues
Whoops! Spoke too soon, it's still adding the hour if the date falls after the
2nd Sunday of March. DOH!
Lisa
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Kemes, Lisa
Sent: Monday, January 11, 2010 10:02 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Issues
Thanks Fred!!
There's that DATEADD function again. (in Homer Simpson's voice
"DATEADDIs there anything it can't do?")
Lisa
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Grooms, Frederick W
Sent: Friday, January 08, 2010 9:45 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Issues
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 ""
- 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: 202
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: 202
STARTDATE: 1173585600
ENDDATE: 1173668400
ENDDATE-STARTDATE: 82800
Axton Grams
On 3/6/07, Easter, David wrote:
> Business Time is not DST aware. This has been true for quite some
> time now, and is probably w
Re: DST Issues
Thanks Fred!!
There's that DATEADD function again. (in Homer Simpson's voice
"DATEADDIs there anything it can't do?")
Lisa
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Grooms, Frederick W
Sent: Friday, January 08, 2010 9:45 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Issues
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 ""
- 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: 202
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: 202
STARTDATE: 1173585600
ENDDATE: 1173668400
ENDDATE-STARTDATE: 82800
Axton Grams
On 3/6/07, Easter, David 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
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 david.sand...@westoverconsulting.co.uk web http://www.westoverconsulting.co.uk -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of lisakemes Sent: 07 January 2010 21:55 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! --- ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
Re: DST Issues
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 ""
- 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: 202
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: 0000202
STARTDATE: 1173585600
ENDDATE: 1173668400
ENDDATE-STARTDATE: 82800
Axton Grams
On 3/6/07, Easter, David 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
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: 202 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: 202 STARTDATE: 1173585600 ENDDATE: 1173668400 ENDDATE-STARTDATE: 82800 Axton Grams On 3/6/07, Easter, David 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,
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: 202 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: 202 STARTDATE: 1173585600 ENDDATE: 1173668400 ENDDATE-STARTDATE: 82800 Axton Grams On 3/6/07, Easter, David 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
DST calc's not correct between dst server site and non-dst problem site
Good afternoon. ARServer 7.1 Client 6.3 and 7.1 Sybase 12.5.4 Solaris 5.9 Has anyone run into the problem of incorrect SLA calculation's where the server site is in DST and the problem location isn't? Our server is located in NJ, and we have customer's in Hong Kong. In the US, during non-DST months, the SLA calculate correctly but, now, during DST months, the SLA calculates one hour short. This is being used on a home grown application, not a Remedy purchased application. Thank you in advance. Marc ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: DST Problem for Server in EMEA
Hi Thomas, Hey thanks.will try out tomorrow on my UAT server and will check for the changes...will let you once done.. Regards, Amey Bhosale On 4/1/08, Thomas Bean <[EMAIL PROTECTED]> wrote: > ** > Amey, > Yes, this will most likely be an issue at each DST change until the related > patches have been applied. > > According to BMC, all of the related DST patches (OS, Java, and ARS must be > applied). Refer to > http://documents.bmc.com/supportu/documents/87/90/68790/68790.pdf > for more detailed information. In particular, this paragraph from the patch > documentation sums it up quite nicely: > > In addition to any BMC-provided patches, the native operating system and > third-party application (including application servers, web servers, > databases, and > Java) patches for DST must be applied to each system. To find out whether > patches are needed and how to obtain them, contact the product vendors. > > There is also an entire section in the document that lists some of the > possible problems that will occur if the AR Server and Mid-Tier are not > patched, such as: > > Display of date/time information in a BMC Remedy Mid Tier web client will be > off by one hour if performed between the "old" DST window and the "new" DST > window (for example, between March 11 and April 1, 2007, or between October > 28 and November 4, 2007). > Functions performed by the mid tier (for example, active links) for web > clients will be off by one hour if performed between the "old" DST window > and the "new" DST window. > Custom Java applications that use the utilities provided by the Java API to > do date-time calculations will be off by one hour if performed between the > "old" DST window and the "new" DST window. > > So, if you decide to patch only the OS and Java, the results will likely be > unpredictable at best. As such, my recommendation to you is to upgrade your > AR Server and Mid-Tier to at least version 6.3 Patch 21, if at all possible, > along with any additional patches to the OS, Java, web server, database, > etc. It will be a headache to be sure, but it will be a worthwhile effort, > IMHO. > > Kind regards, > > Thomas Bean > > - Original Message - > From: "AMEY BHOSALE" <[EMAIL PROTECTED]> > Newsgroups: gmane.comp.crm.arsystem.general > To: > Sent: Monday, March 31, 2008 5:31 PM > Subject: Re: DST Problem for Server in EMEA > > > Hi Thomas, > > > > Thanks for the details...but would like to ask you that our AR System > > Server will mainly pickup the files from Java and OS for to work it > > over midtier.So if we directly update the the Java and OS files wont > > if be possible. > > > > And if we dont apply the patch wont it affect the users next > > time..so there needs to be some solution to overcome this > > issue. > > > > So managing these changes to US DST requires updates to the underlying > > JVM and OS being used by WLS > > > > WebLogicServer <-> Java Virtual Machine <-> OS. > > > > Correct me if i am wrong... > > > > Let me know your views on this and what can be the best possible solution. > > > > Warm regards, > > > > Amey Bhosale > > > > > > > > On 4/1/08, Thomas Bean <[EMAIL PROTECTED]> wrote: > >> ** > >> > >> Hello Amey, > >> This is from > http://webexhibits.org/daylightsaving/b2.html: > >> > >> > >> When we change our clocks > >> > >> Most of the United States begins Daylight Saving Time at 2:00 a.m. on the > second Sunday in March and reverts to standard time on the first Sunday in > November. In the U.S., each time zone switches at a different time. > >> > >> In the European Union, Summer Time begins and ends at 1:00 a.m. Universal > Time (Greenwich Mean Time). It begins the last Sunday in March and ends the > last Sunday in October. In the EU, all time zones change at the same moment. > >> > >> So, if the issues just started appearing today, then I would guess that > it had something to do with the UK-based server switching to DST yesterday > (March 30th), and the fact that DST would not be in effect in the US until > April 6 this year, if the pre-2007 DST rules were still in effect (prior to > 2007, the DST start date in the US was set to the first Sunday in April). > >> > >> So, if you don't apply the patch to your server, then I am guessing that > the issue will probably only affect your users this week. After April 6, > I'm guessing ev
Re: DST Problem for Server in EMEA
Amey, Yes, this will most likely be an issue at each DST change until the related patches have been applied. According to BMC, all of the related DST patches (OS, Java, and ARS must be applied). Refer to http://documents.bmc.com/supportu/documents/87/90/68790/68790.pdf for more detailed information. In particular, this paragraph from the patch documentation sums it up quite nicely: In addition to any BMC-provided patches, the native operating system and third-party application (including application servers, web servers, databases, and Java) patches for DST must be applied to each system. To find out whether patches are needed and how to obtain them, contact the product vendors. There is also an entire section in the document that lists some of the possible problems that will occur if the AR Server and Mid-Tier are not patched, such as: a.. Display of date/time information in a BMC Remedy Mid Tier web client will be off by one hour if performed between the "old" DST window and the "new" DST window (for example, between March 11 and April 1, 2007, or between October 28 and November 4, 2007). b.. Functions performed by the mid tier (for example, active links) for web clients will be off by one hour if performed between the "old" DST window and the "new" DST window. c.. Custom Java applications that use the utilities provided by the Java API to do date-time calculations will be off by one hour if performed between the "old" DST window and the "new" DST window. So, if you decide to patch only the OS and Java, the results will likely be unpredictable at best. As such, my recommendation to you is to upgrade your AR Server and Mid-Tier to at least version 6.3 Patch 21, if at all possible, along with any additional patches to the OS, Java, web server, database, etc. It will be a headache to be sure, but it will be a worthwhile effort, IMHO. Kind regards, Thomas Bean - Original Message - From: "AMEY BHOSALE" <[EMAIL PROTECTED]> Newsgroups: gmane.comp.crm.arsystem.general To: Sent: Monday, March 31, 2008 5:31 PM Subject: Re: DST Problem for Server in EMEA > Hi Thomas, > > Thanks for the details...but would like to ask you that our AR System > Server will mainly pickup the files from Java and OS for to work it > over midtier.So if we directly update the the Java and OS files wont > if be possible. > > And if we dont apply the patch wont it affect the users next > time......so there needs to be some solution to overcome this > issue. > > So managing these changes to US DST requires updates to the underlying > JVM and OS being used by WLS > > WebLogicServer <-> Java Virtual Machine <-> OS. > > Correct me if i am wrong... > > Let me know your views on this and what can be the best possible solution. > > Warm regards, > > Amey Bhosale > > > > On 4/1/08, Thomas Bean <[EMAIL PROTECTED]> wrote: >> ** >> >> Hello Amey, >> This is from http://webexhibits.org/daylightsaving/b2.html: >> >> >> When we change our clocks >> >> Most of the United States begins Daylight Saving Time at 2:00 a.m. on the >> second Sunday in March and reverts to standard time on the first Sunday in >> November. In the U.S., each time zone switches at a different time. >> >> In the European Union, Summer Time begins and ends at 1:00 a.m. Universal >> Time (Greenwich Mean Time). It begins the last Sunday in March and ends the >> last Sunday in October. In the EU, all time zones change at the same moment. >> >> So, if the issues just started appearing today, then I would guess that it >> had something to do with the UK-based server switching to DST yesterday >> (March 30th), and the fact that DST would not be in effect in the US until >> April 6 this year, if the pre-2007 DST rules were still in effect (prior to >> 2007, the DST start date in the US was set to the first Sunday in April). >> >> So, if you don't apply the patch to your server, then I am guessing that the >> issue will probably only affect your users this week. After April 6, I'm >> guessing everything should be back to normal. >> >> As for loading only the OS or Java patches, and leaving the AR Server >> unpatched -- this will probably *not* work. See the earlier message from >> David Easter dated March 12, 2008 under the subject "Re: DST update..." for >> more info (message is attached). >> >> HTH, >> >> Thomas Bean >> >> - Original Message - >> From: "Amey Bhosale" <[EMAIL PROTECTED]> >> Newsgroups: gmane.comp.crm.arsystem.general >> To: >
Re: DST Problem for Server in EMEA
Hi Thomas, Thanks for the details...but would like to ask you that our AR System Server will mainly pickup the files from Java and OS for to work it over midtier.So if we directly update the the Java and OS files wont if be possible. And if we dont apply the patch wont it affect the users next time..so there needs to be some solution to overcome this issue. So managing these changes to US DST requires updates to the underlying JVM and OS being used by WLS WebLogicServer <-> Java Virtual Machine <-> OS. Correct me if i am wrong... Let me know your views on this and what can be the best possible solution. Warm regards, Amey Bhosale On 4/1/08, Thomas Bean <[EMAIL PROTECTED]> wrote: > ** > > Hello Amey, > This is from http://webexhibits.org/daylightsaving/b2.html: > > > When we change our clocks > > Most of the United States begins Daylight Saving Time at 2:00 a.m. on the > second Sunday in March and reverts to standard time on the first Sunday in > November. In the U.S., each time zone switches at a different time. > > In the European Union, Summer Time begins and ends at 1:00 a.m. Universal > Time (Greenwich Mean Time). It begins the last Sunday in March and ends the > last Sunday in October. In the EU, all time zones change at the same moment. > > So, if the issues just started appearing today, then I would guess that it > had something to do with the UK-based server switching to DST yesterday > (March 30th), and the fact that DST would not be in effect in the US until > April 6 this year, if the pre-2007 DST rules were still in effect (prior to > 2007, the DST start date in the US was set to the first Sunday in April). > > So, if you don't apply the patch to your server, then I am guessing that the > issue will probably only affect your users this week. After April 6, I'm > guessing everything should be back to normal. > > As for loading only the OS or Java patches, and leaving the AR Server > unpatched -- this will probably *not* work. See the earlier message from > David Easter dated March 12, 2008 under the subject "Re: DST update..." for > more info (message is attached). > > HTH, > > Thomas Bean > > - Original Message - > From: "Amey Bhosale" <[EMAIL PROTECTED]> > Newsgroups: gmane.comp.crm.arsystem.general > To: > Sent: Monday, March 31, 2008 3:56 PM > Subject: DST Problem for Server in EMEA > > > Hi All, > > > > We are currently working on ARS 6.3 Patch 12 and Midtier 6.3 Patch 13 on > > SunOS 5.8 with a Solaris based server and having a problem with the users > > in North America with the DST (Day Light Saving) changes.As per my > > knowledge DST changes every year and from the year 2007 there has been a > > change where the DST change occurs second Sunday of March and ends in > > November. > > > > We obeserved today that many of our users in North America are having > > problem with the Date/Time Field as they seem to have one hour lagging > > behind the server time which is in UK (EMEA) > > > > I do know that we have a Patch 21 for this but also heard that instead of > > installing Patch we can directly add the Java files into the Java Directory > > which will take care of that. > > > > Can someone please help me out on this...as we are having a major issue. > > > > > > Warm Regards, > > > > Amey Bhosale > > > > > > > > > > > > - > > Forgot the famous last words? Access your message archive online. Click > > here.__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > html___ > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: DST Problem for Server in EMEA
Hello Amey, This is from http://webexhibits.org/daylightsaving/b2.html: When we change our clocks Most of the United States begins Daylight Saving Time at 2:00 a.m. on the second Sunday in March and reverts to standard time on the first Sunday in November. In the U.S., each time zone switches at a different time. In the European Union, Summer Time begins and ends at 1:00 a.m. Universal Time (Greenwich Mean Time). It begins the last Sunday in March and ends the last Sunday in October. In the EU, all time zones change at the same moment. So, if the issues just started appearing today, then I would guess that it had something to do with the UK-based server switching to DST yesterday (March 30th), and the fact that DST would not be in effect in the US until April 6 this year, if the pre-2007 DST rules were still in effect (prior to 2007, the DST start date in the US was set to the first Sunday in April). So, if you don't apply the patch to your server, then I am guessing that the issue will probably only affect your users this week. After April 6, I'm guessing everything should be back to normal. As for loading only the OS or Java patches, and leaving the AR Server unpatched -- this will probably *not* work. See the earlier message from David Easter dated March 12, 2008 under the subject "Re: DST update..." for more info (message is attached). HTH, Thomas Bean - Original Message - From: "Amey Bhosale" <[EMAIL PROTECTED]> Newsgroups: gmane.comp.crm.arsystem.general To: Sent: Monday, March 31, 2008 3:56 PM Subject: DST Problem for Server in EMEA > Hi All, > > We are currently working on ARS 6.3 Patch 12 and Midtier 6.3 Patch 13 on > SunOS 5.8 with a Solaris based server and having a problem with the users in > North America with the DST (Day Light Saving) changes.As per my knowledge DST > changes every year and from the year 2007 there has been a change where the > DST change occurs second Sunday of March and ends in November. > > We obeserved today that many of our users in North America are having > problem with the Date/Time Field as they seem to have one hour lagging behind > the server time which is in UK (EMEA) > > I do know that we have a Patch 21 for this but also heard that instead of > installing Patch we can directly add the Java files into the Java Directory > which will take care of that. > > Can someone please help me out on this...as we are having a major issue. > > > Warm Regards, > > Amey Bhosale > > > > > > - > Forgot the famous last words? Access your message archive online. Click here. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"From: "Easter, David" <[EMAIL PROTECTED]> To: Subject: Re: DST update... Date: Wednesday, March 12, 2008 12:19 PM Just loading the OS and Java patches will not be sufficient. The additional patch must be loaded. The technical bulletin goes into a lot of detail on this issue. 06-Mar-2007 Daylight Saving Time (DST) and BMC Remedy Action Request System 6.03 PDF <http://www.bmc.com/supportu/documents/87/90/68790/68790.pdf> http://www.bmc.com/supportu/documents/87/90/68790/68790.pdf -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. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Richard Copits Sent: Wednesday, March 12, 2008 6:21 AM To: arslist@ARSLIST.ORG Subject: DST update... ** We're planning on (belatedly) updating our 6.3 to take into account the DST time change. Looking at the documentation, it looks like we need to have the server LAN folks do some updates and we need to apply patch #21 to Remedy AR Server. Is this the only patch we'll need? Also, I tried downloading the patch from the Remedy Heritage patch site and get an FTP error that the download can't find the file on their endsigh Do I really need it or will just the OS patches work? Thanks... "The three men I admire most are Curly, Larry and Moe" Meat Loaf Portions of this message may be confidential under an exemption to Ohio's public records law or under a legal privilege. If you have r
DST Problem for Server in EMEA
Hi All, We are currently working on ARS 6.3 Patch 12 and Midtier 6.3 Patch 13 on SunOS 5.8 with a Solaris based server and having a problem with the users in North America with the DST (Day Light Saving) changes.As per my knowledge DST changes every year and from the year 2007 there has been a change where the DST change occurs second Sunday of March and ends in November. We obeserved today that many of our users in North America are having problem with the Date/Time Field as they seem to have one hour lagging behind the server time which is in UK (EMEA) I do know that we have a Patch 21 for this but also heard that instead of installing Patch we can directly add the Java files into the Java Directory which will take care of that. Can someone please help me out on this...as we are having a major issue. Warm Regards, Amey Bhosale - Forgot the famous last words? Access your message archive online. Click here. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: DST - Leap Year Issue with Date Only fields
# of days since January 1, 4713 B.C., using a hybrid of the Julian and
Gregorian calendar systems (similar to the Oracle calendar -- see
http://www.orafaq.com/papers/dates_o.doc).
- Original Message -
From: "Shawn Stonequist" <[EMAIL PROTECTED]>
Newsgroups: gmane.comp.crm.arsystem.general
To:
Sent: Wednesday, March 12, 2008 3:27 PM
Subject: Re: DST - Leap Year Issue with Date Only fields
Does anyone know how the Date (not Date/Time displayed as Date Only) data
is
stored?
For instance, we know Date/Time fields (regardless of how they are
displayed) are actually stored as Epoch/Unix time.
Thanks in advance!
Shawn Stonequist
EMNS Inc.
-Original Message-
From: Michelle L [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2008 1:54 PM
Subject: Re: DST - Leap Year Issue with Date Only fields
Hi, Randy:
Thank you for your response. But, we're already on ARS 6.3 Patch 23. Was
there another patch to address this. Is this patch generally available or
is it something that you have to specifically request.
Thanks,
Michelle
Randy Simon
<[EMAIL PROTECTED]>
Sent by: "Action To
Request Systemarslist@ARSLIST.ORG
discussion cc
list(ARSList)"
<[EMAIL PROTECTED] Subject
ORG> Re: DST - Leap Year Issue with Date
Only fields
03/12/2008 11:30
AM
Please respond to
[EMAIL PROTECTED]
RG
If you are on ARS 6.3 there is a patch for this problem.
We had the same problem, but we are on 6.0 and would need to upgrade to
6.3 and install the patch.
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Michelle L
Sent: Wednesday, March 12, 2008 11:29 AM
To: arslist@ARSLIST.ORG
Subject: DST - Leap Year Issue with Date Only fields
Hey Y'all:
Remedy ARS 6.3 P23 (Server is in Central time zone) Windows 2003 SQL
Server
2000 Admin tool ARS 6.3 P23 User Tool 6.3 P23 and 7.0.1 Patch 005
We're not sure if this issue is DST only related or DST and Leap Year
related.
We discovered an interesting phenomenon when we reviewed records in
various
forms with Date fields (not Date/Time). On March 9, 2008 starting at 3:00
AM and continuing through the remainder of the day, any Date field set
with
$DATE$ was set to March 8, 2008. It didn't matter what time of day it
was.
Date/Time fields were appropriately set to March 9, 2008 and current time.
We had to update thousands of records in various forms.
Did anyone who is still on Remedy ARS 6.3 experience this?
Thanks,
Michelle
==
Confidentiality Notice: The information contained in and transmitted with
this communication is strictly confidential, is intended only for the use
of
the intended recipient, and is the property of Countrywide Financial
Corporation or its affiliates and subsidiaries. If you are not the
intended
recipient, you are hereby notified that any use of the information
contained
in or transmitted with the communication or dissemination, distribution,
or
copying of this communication is strictly prohibited by law. If you have
received this communication in error, please immediately return this
communication to the sender and delete the original message and any copy
of
it in your possession.
==
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor:
www.rmsportal.com ARSlist: "Where the Answers Are"
STATEMENT OF CONFIDENTIALITY:
The information contained in this message or any attachments to this
message
are intended only for the person(s) or entity to which it is addressed and
may contain confidential and/or privileged material as well as being
protected from disclosure.
Any review, retransmission, dissemination or other use of, or taking of
any
action in reliance upon, this information by persons or entities other
than
the intended recipient is strictly prohibited. If you received this in
error, please contact us immediately and delete the material from any
computer.
Thank You.
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum
Sponsor:
www.rmsportal.com ARSlist: "Where the Answers Are"
==
Confidentiality Notice: The information con
Re: DST - Leap Year Issue with Date Only fields
Does anyone know how the Date (not Date/Time displayed as Date Only) data is stored? For instance, we know Date/Time fields (regardless of how they are displayed) are actually stored as Epoch/Unix time. Thanks in advance! Shawn Stonequist EMNS Inc. -Original Message- From: Michelle L [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2008 1:54 PM Subject: Re: DST - Leap Year Issue with Date Only fields Hi, Randy: Thank you for your response. But, we're already on ARS 6.3 Patch 23. Was there another patch to address this. Is this patch generally available or is it something that you have to specifically request. Thanks, Michelle Randy Simon <[EMAIL PROTECTED]> Sent by: "Action To Request Systemarslist@ARSLIST.ORG discussion cc list(ARSList)" <[EMAIL PROTECTED] Subject ORG> Re: DST - Leap Year Issue with Date Only fields 03/12/2008 11:30 AM Please respond to [EMAIL PROTECTED] RG If you are on ARS 6.3 there is a patch for this problem. We had the same problem, but we are on 6.0 and would need to upgrade to 6.3 and install the patch. -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Michelle L Sent: Wednesday, March 12, 2008 11:29 AM To: arslist@ARSLIST.ORG Subject: DST - Leap Year Issue with Date Only fields Hey Y'all: Remedy ARS 6.3 P23 (Server is in Central time zone) Windows 2003 SQL Server 2000 Admin tool ARS 6.3 P23 User Tool 6.3 P23 and 7.0.1 Patch 005 We're not sure if this issue is DST only related or DST and Leap Year related. We discovered an interesting phenomenon when we reviewed records in various forms with Date fields (not Date/Time). On March 9, 2008 starting at 3:00 AM and continuing through the remainder of the day, any Date field set with $DATE$ was set to March 8, 2008. It didn't matter what time of day it was. Date/Time fields were appropriately set to March 9, 2008 and current time. We had to update thousands of records in various forms. Did anyone who is still on Remedy ARS 6.3 experience this? Thanks, Michelle == Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession. == ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" STATEMENT OF CONFIDENTIALITY: The information contained in this message or any attachments to this message are intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material as well as being protected from disclosure. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibit
Re: DST - Leap Year Issue with Date Only fields
Hi, Randy: Thank you for your response. But, we're already on ARS 6.3 Patch 23. Was there another patch to address this. Is this patch generally available or is it something that you have to specifically request. Thanks, Michelle Randy Simon <[EMAIL PROTECTED]> Sent by: "Action To Request Systemarslist@ARSLIST.ORG discussion cc list(ARSList)" <[EMAIL PROTECTED] Subject ORG> Re: DST - Leap Year Issue with Date Only fields 03/12/2008 11:30 AM Please respond to [EMAIL PROTECTED] RG If you are on ARS 6.3 there is a patch for this problem. We had the same problem, but we are on 6.0 and would need to upgrade to 6.3 and install the patch. -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Michelle L Sent: Wednesday, March 12, 2008 11:29 AM To: arslist@ARSLIST.ORG Subject: DST - Leap Year Issue with Date Only fields Hey Y'all: Remedy ARS 6.3 P23 (Server is in Central time zone) Windows 2003 SQL Server 2000 Admin tool ARS 6.3 P23 User Tool 6.3 P23 and 7.0.1 Patch 005 We're not sure if this issue is DST only related or DST and Leap Year related. We discovered an interesting phenomenon when we reviewed records in various forms with Date fields (not Date/Time). On March 9, 2008 starting at 3:00 AM and continuing through the remainder of the day, any Date field set with $DATE$ was set to March 8, 2008. It didn't matter what time of day it was. Date/Time fields were appropriately set to March 9, 2008 and current time. We had to update thousands of records in various forms. Did anyone who is still on Remedy ARS 6.3 experience this? Thanks, Michelle == Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession. == ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" STATEMENT OF CONFIDENTIALITY: The information contained in this message or any attachments to this message are intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material as well as being protected from disclosure. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibited. If you received this in error, please contact us immediately and delete the material from any computer. Thank You. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" == Confidentia
Re: DST - Leap Year Issue with Date Only fields
Hi, Thomas:
Thank you for responding. I appreciate the sanity check. I just checked
records from the DST change last year on March 11, 2007. You're right the
same thing happened. Those records that were created on March 11, 2007,
show a date in one of the DATE fields as March 10, 2007.
I'm pretty sure they were on ARS 6.3 Patch 20 at the time. (I wasn't here
yet)
So, in my honest opinion, all of the kinks have NOT been worked out for
DST, whether one is on patch 20 or 23.
To be on the safe side, we restarted the services on our servers on Monday
night. The good news is that beginning on the following Monday at
midnight, it all seemed to work itself out.
Thanks,
Michelle
Thomas Bean
<[EMAIL PROTECTED]>
Sent by: "Action To
Request Systemarslist@ARSLIST.ORG
discussion cc
list(ARSList)"
<[EMAIL PROTECTED] Subject
ORG> Re: DST - Leap Year Issue with Date
Only fields
03/12/2008 11:07
AM
Please respond to
[EMAIL PROTECTED]
RG
Hi Michelle,
I believe I encountered the same issue you are describing on a 5.01.02 AR
Server back in 2006. I reported the issue to BMC Support, and the issue
was
closed with a defect (SW00220325). See attached for a copy of the issue.
I
never received any follow up on the defect (go figure), but when I looked
it
up today, this is what it shows:
ID: SW00220325
Disposition: Verified
Resolution: Not Reproducible
Product: AR System
Version: 6.00.01
Problem Area 1: Server
Summary:
I am running ARS 6.0.1 on a Windows 2000 Server. The server is set to
automatically adjust for Daylights saving time. For the past two years on
the day of the time change, the Date keyword renders the previous date.
And
on the next day at midnight
The defect was submitted for another customer who encountered the same
issue, so I am surprised that BMC was unable to reproduce it. I haven't
tested to see if it has been corrected in ARS 7.0.1+.
The issue seems to be related to the DST change, not leap year.
--Thomas
- Original Message -
From: "Michelle L" <[EMAIL PROTECTED]>
Newsgroups: gmane.comp.crm.arsystem.general
To:
Sent: Wednesday, March 12, 2008 10:28 AM
Subject: DST - Leap Year Issue with Date Only fields
> Hey Y'all:
>
> Remedy ARS 6.3 P23 (Server is in Central time zone)
> Windows 2003
> SQL Server 2000
> Admin tool ARS 6.3 P23
> User Tool 6.3 P23 and 7.0.1 Patch 005
>
> We're not sure if this issue is DST only related or DST and Leap Year
> related.
>
> We discovered an interesting phenomenon when we reviewed records in
> various
> forms with Date fields (not Date/Time). On March 9, 2008 starting at
3:00
> AM and continuing through the remainder of the day, any Date field set
> with
> $DATE$ was set to March 8, 2008. It didn't matter what time of day it
> was.
> Date/Time fields were appropriately set to March 9, 2008 and current
time.
>
> We had to update thousands of records in various forms.
>
> Did anyone who is still on Remedy ARS 6.3 experience this?
>
> Thanks,
> Michelle
>
>
>
> ==
>
> Confidentiality Notice: The information contained in and transmitted with
> this communication is strictly confidential, is intended only for the use
> of the intended recipient, and is the property of Countrywide Financial
> Corporation or its affiliates and subsidiaries. If you are not the
> intended recipient, you are hereby notified that any use of the
> information contained in or transmitted with the communication or
> dissemination, distribution, or copying of this
Re: DST update...
Thank you! Exactly what I need...!! From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David Sent: Wednesday, March 12, 2008 1:19 PM To: arslist@ARSLIST.ORG Subject: Re: DST update... ** Just loading the OS and Java patches will not be sufficient. The additional patch must be loaded. The technical bulletin goes into a lot of detail on this issue. 06-Mar-2007 Daylight Saving Time (DST) and BMC Remedy Action Request System 6.03 PDF <http://www.bmc.com/supportu/documents/87/90/68790/68790.pdf> http://www.bmc.com/supportu/documents/87/90/68790/68790.pdf -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. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Richard Copits Sent: Wednesday, March 12, 2008 6:21 AM To: arslist@ARSLIST.ORG Subject: DST update... ** We're planning on (belatedly) updating our 6.3 to take into account the DST time change. Looking at the documentation, it looks like we need to have the server LAN folks do some updates and we need to apply patch #21 to Remedy AR Server. Is this the only patch we'll need? Also, I tried downloading the patch from the Remedy Heritage patch site and get an FTP error that the download can't find the file on their endsigh Do I really need it or will just the OS patches work? Thanks... "The three men I admire most are Curly, Larry and Moe" Meat Loaf Portions of this message may be confidential under an exemption to Ohio's public records law or under a legal privilege. If you have received this message in error or due to an unauthorized transmission or interception, please delete all copies from your system without disclosing, copying, or transmitting this message. __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ Portions of this message may be confidential under an exemption to Ohio's public records law or under a legal privilege. If you have received this message in error or due to an unauthorized transmission or interception, please delete all copies from your system without disclosing, copying, or transmitting this message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: DST update...
Just loading the OS and Java patches will not be sufficient. The additional patch must be loaded. The technical bulletin goes into a lot of detail on this issue. 06-Mar-2007 Daylight Saving Time (DST) and BMC Remedy Action Request System 6.03 PDF <http://www.bmc.com/supportu/documents/87/90/68790/68790.pdf> http://www.bmc.com/supportu/documents/87/90/68790/68790.pdf -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. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Richard Copits Sent: Wednesday, March 12, 2008 6:21 AM To: arslist@ARSLIST.ORG Subject: DST update... ** We're planning on (belatedly) updating our 6.3 to take into account the DST time change. Looking at the documentation, it looks like we need to have the server LAN folks do some updates and we need to apply patch #21 to Remedy AR Server. Is this the only patch we'll need? Also, I tried downloading the patch from the Remedy Heritage patch site and get an FTP error that the download can't find the file on their endsigh Do I really need it or will just the OS patches work? Thanks... "The three men I admire most are Curly, Larry and Moe" Meat Loaf Portions of this message may be confidential under an exemption to Ohio's public records law or under a legal privilege. If you have received this message in error or due to an unauthorized transmission or interception, please delete all copies from your system without disclosing, copying, or transmitting this message. __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: DST - Leap Year Issue with Date Only fields
When we ran into DST issues, we had to take out the Time Zone value setting it to NULL. It actually in our case comes down to a MSFT dll that needs to be fixed. The Remedy User tools uses that dlls for some of it's date manipulations. We couldn't roll out the dll, because it would require us to test all our VB, etc apps. Just to much of a time eater, easier just to set the time zone in the user tool. As a side note, when this happened I checked in the database, and it was storing the dates correctly. Randy -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Bean Sent: Wednesday, March 12, 2008 11:07 AM To: arslist@ARSLIST.ORG Subject: Re: DST - Leap Year Issue with Date Only fields Hi Michelle, I believe I encountered the same issue you are describing on a 5.01.02 AR Server back in 2006. I reported the issue to BMC Support, and the issue was closed with a defect (SW00220325). See attached for a copy of the issue. I never received any follow up on the defect (go figure), but when I looked it up today, this is what it shows: ID: SW00220325 Disposition: Verified Resolution: Not Reproducible Product: AR System Version: 6.00.01 Problem Area 1: Server Summary: I am running ARS 6.0.1 on a Windows 2000 Server. The server is set to automatically adjust for Daylights saving time. For the past two years on the day of the time change, the Date keyword renders the previous date. And on the next day at midnight The defect was submitted for another customer who encountered the same issue, so I am surprised that BMC was unable to reproduce it. I haven't tested to see if it has been corrected in ARS 7.0.1+. The issue seems to be related to the DST change, not leap year. --Thomas - Original Message - From: "Michelle L" <[EMAIL PROTECTED]> Newsgroups: gmane.comp.crm.arsystem.general To: Sent: Wednesday, March 12, 2008 10:28 AM Subject: DST - Leap Year Issue with Date Only fields > Hey Y'all: > > Remedy ARS 6.3 P23 (Server is in Central time zone) > Windows 2003 > SQL Server 2000 > Admin tool ARS 6.3 P23 > User Tool 6.3 P23 and 7.0.1 Patch 005 > > We're not sure if this issue is DST only related or DST and Leap Year > related. > > We discovered an interesting phenomenon when we reviewed records in > various > forms with Date fields (not Date/Time). On March 9, 2008 starting at 3:00 > AM and continuing through the remainder of the day, any Date field set > with > $DATE$ was set to March 8, 2008. It didn't matter what time of day it > was. > Date/Time fields were appropriately set to March 9, 2008 and current time. > > We had to update thousands of records in various forms. > > Did anyone who is still on Remedy ARS 6.3 experience this? > > Thanks, > Michelle > > > > == > > Confidentiality Notice: The information contained in and transmitted with > this communication is strictly confidential, is intended only for the use > of the intended recipient, and is the property of Countrywide Financial > Corporation or its affiliates and subsidiaries. If you are not the > intended recipient, you are hereby notified that any use of the > information contained in or transmitted with the communication or > dissemination, distribution, or copying of this communication is strictly > prohibited by law. If you have received this communication in error, > please immediately return this communication to the sender and delete the > original message and any copy of it in your possession. > > == > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: DST - Leap Year Issue with Date Only fields
If you are on ARS 6.3 there is a patch for this problem. We had the same problem, but we are on 6.0 and would need to upgrade to 6.3 and install the patch. -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Michelle L Sent: Wednesday, March 12, 2008 11:29 AM To: arslist@ARSLIST.ORG Subject: DST - Leap Year Issue with Date Only fields Hey Y'all: Remedy ARS 6.3 P23 (Server is in Central time zone) Windows 2003 SQL Server 2000 Admin tool ARS 6.3 P23 User Tool 6.3 P23 and 7.0.1 Patch 005 We're not sure if this issue is DST only related or DST and Leap Year related. We discovered an interesting phenomenon when we reviewed records in various forms with Date fields (not Date/Time). On March 9, 2008 starting at 3:00 AM and continuing through the remainder of the day, any Date field set with $DATE$ was set to March 8, 2008. It didn't matter what time of day it was. Date/Time fields were appropriately set to March 9, 2008 and current time. We had to update thousands of records in various forms. Did anyone who is still on Remedy ARS 6.3 experience this? Thanks, Michelle == Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession. == ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" STATEMENT OF CONFIDENTIALITY: The information contained in this message or any attachments to this message are intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material as well as being protected from disclosure. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibited. If you received this in error, please contact us immediately and delete the material from any computer. Thank You. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: DST - Leap Year Issue with Date Only fields
Hi Michelle, I believe I encountered the same issue you are describing on a 5.01.02 AR Server back in 2006. I reported the issue to BMC Support, and the issue was closed with a defect (SW00220325). See attached for a copy of the issue. I never received any follow up on the defect (go figure), but when I looked it up today, this is what it shows: ID: SW00220325 Disposition: Verified Resolution: Not Reproducible Product: AR System Version: 6.00.01 Problem Area 1: Server Summary: I am running ARS 6.0.1 on a Windows 2000 Server. The server is set to automatically adjust for Daylights saving time. For the past two years on the day of the time change, the Date keyword renders the previous date. And on the next day at midnight The defect was submitted for another customer who encountered the same issue, so I am surprised that BMC was unable to reproduce it. I haven't tested to see if it has been corrected in ARS 7.0.1+. The issue seems to be related to the DST change, not leap year. --Thomas - Original Message - From: "Michelle L" <[EMAIL PROTECTED]> Newsgroups: gmane.comp.crm.arsystem.general To: Sent: Wednesday, March 12, 2008 10:28 AM Subject: DST - Leap Year Issue with Date Only fields Hey Y'all: Remedy ARS 6.3 P23 (Server is in Central time zone) Windows 2003 SQL Server 2000 Admin tool ARS 6.3 P23 User Tool 6.3 P23 and 7.0.1 Patch 005 We're not sure if this issue is DST only related or DST and Leap Year related. We discovered an interesting phenomenon when we reviewed records in various forms with Date fields (not Date/Time). On March 9, 2008 starting at 3:00 AM and continuing through the remainder of the day, any Date field set with $DATE$ was set to March 8, 2008. It didn't matter what time of day it was. Date/Time fields were appropriately set to March 9, 2008 and current time. We had to update thousands of records in various forms. Did anyone who is still on Remedy ARS 6.3 experience this? Thanks, Michelle == Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession. == ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ISS00946302.pdf Description: Adobe PDF document
Re: DST - Leap Year Issue with Date Only fields
See what happens if you take your Time Zone off. The date only fields store the date as 3/8/2008 12:00 AM. If we have our time zone (CST), it make everything an hour off. -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Michelle L Sent: Wednesday, March 12, 2008 10:29 AM To: arslist@ARSLIST.ORG Subject: DST - Leap Year Issue with Date Only fields Hey Y'all: Remedy ARS 6.3 P23 (Server is in Central time zone) Windows 2003 SQL Server 2000 Admin tool ARS 6.3 P23 User Tool 6.3 P23 and 7.0.1 Patch 005 We're not sure if this issue is DST only related or DST and Leap Year related. We discovered an interesting phenomenon when we reviewed records in various forms with Date fields (not Date/Time). On March 9, 2008 starting at 3:00 AM and continuing through the remainder of the day, any Date field set with $DATE$ was set to March 8, 2008. It didn't matter what time of day it was. Date/Time fields were appropriately set to March 9, 2008 and current time. We had to update thousands of records in various forms. Did anyone who is still on Remedy ARS 6.3 experience this? Thanks, Michelle == Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession. == ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
DST - Leap Year Issue with Date Only fields
Hey Y'all: Remedy ARS 6.3 P23 (Server is in Central time zone) Windows 2003 SQL Server 2000 Admin tool ARS 6.3 P23 User Tool 6.3 P23 and 7.0.1 Patch 005 We're not sure if this issue is DST only related or DST and Leap Year related. We discovered an interesting phenomenon when we reviewed records in various forms with Date fields (not Date/Time). On March 9, 2008 starting at 3:00 AM and continuing through the remainder of the day, any Date field set with $DATE$ was set to March 8, 2008. It didn't matter what time of day it was. Date/Time fields were appropriately set to March 9, 2008 and current time. We had to update thousands of records in various forms. Did anyone who is still on Remedy ARS 6.3 experience this? Thanks, Michelle == Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession. == ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
DST update...
We're planning on (belatedly) updating our 6.3 to take into account the DST time change. Looking at the documentation, it looks like we need to have the server LAN folks do some updates and we need to apply patch #21 to Remedy AR Server. Is this the only patch we'll need? Also, I tried downloading the patch from the Remedy Heritage patch site and get an FTP error that the download can't find the file on their endsigh Do I really need it or will just the OS patches work? Thanks... "The three men I admire most are Curly, Larry and Moe" Meat Loaf Portions of this message may be confidential under an exemption to Ohio's public records law or under a legal privilege. If you have received this message in error or due to an unauthorized transmission or interception, please delete all copies from your system without disclosing, copying, or transmitting this message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
DST: Import Tool, Escalation (6.0.3 p20)
ARS 6.0.3 p20 installed on March 6. win 2003, SQL 2000. Import Tool 6.0.3 p20: Last Modified Date is OK, but field, wich was imported with $DATE$ shows 3/14/2007 1:00:00 AM (User Tool p20). eMail Escalation Notification setup to fire at 3PM goes on at 4PM. ii PS: Did you hear that GOV agencies moving HD/CH/AM from Remedy to CA paltform? ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
DST problem - can't modify tickets
Hello, We have a strange problem with Remedy AR, every year when we push the clock back one hour any tickets created within that hour cannot be updated by users. There is no problem for the Administrators, or AR_Escalator or our CA Unicentre interface. When I turn on the logs we get a ARSetEntry API call failure and error 330 "You do not have write access to field." pops up in the client, but the field is a public field. We are using artime. And our system is: AR 5.1.2, Sybase 12.5 and HP-UX B.11.11 Any insight would be greatly appreciated. Rob Robert Rozanski CGI-Integrated Technology Management 2480 Meadowvale Blvd., Suite 100 Mississauga, Ontario L5N 8M6 Tel: 905-858-7100 ext 7552 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
Re: Possible DST Issue
Hi, Stephen: I did find a bug ID for the issue you addressed below. It is allegedly fixed in Mid-Tier 7.0.1 Patch 004. SW00266823 Certain dates, such as 11/01/2007, are corrupted on the Mid Tier. Thanks, Michelle "Heider, Stephen" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 11/02/2007 09:19 AM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Possible DST Issue ** Michelle, I am not aware of any bug defect with this. Since this ?bug? will go away in 3 days anyways I hadn?t planned on submitting a bug report. BTW, because of the nature of dates and time changes, moving forward I plan to always set dates to character fields before sending to SQL. This way, it shouldn?t matter when the time changes. BTW #2, I recently read somewhere online that the Act that changed DST time in the US has a clause that allows Congress to revert back to the original DST time if they want to. When/if that happens then ARS, Java, OS?s and other programs will need to be modified once again. T-Shirt idea: Just say ?No? to Daylight Saving Time Stephen Remedy Skilled Professional From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Michelle L Sent: Friday, November 02, 2007 9:57 AM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue ** Hi, Stephen: Thank you for the workaround and passing this along to the masses. Is there already a defect id for this? Thanks, Michelle "Heider, Stephen" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 11/02/2007 07:37 AM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Possible DST Issue ** Just wanted to pass this along? ARS 6.3 p22 (server, mid-tier, user tool), SQL Server 2000 (all patches), Windows Server 2003 (all patches). When passing a date in a date field within an active link to a Set Fields SQL User Defined Function Remedy changes the date to the previous day. This only occurs for dates starting this last Sunday through this coming Sunday. The work-around is to set the date field to a tmp character field first, then pass the tmp character field to the SQL user defined function. HTH Stephen Remedy Skilled Professional From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Thursday, November 01, 2007 5:09 PM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue Wow! That's weird. Does that happen from the native client too? Just for information purposes - what if you save it on the mid tier and then view the record from the mid-tier? What is the date displayed as? Also if you save from the native client does it display it correctly on the mid-tier? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Suwanski, Ron Sent: Thursday, November 01, 2007 4:25 PM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue ** Yes I saw it too.. but it was only for 11/1/2007. If you try 11/2/2007 it is fine.. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Frank Caruso Sent: Thursday, November 01, 2007 12:51 PM To: arslist@ARSLIST.ORG Subject: Possible DST Issue ** ARS 6.3 p20 Solairs\Sybase MidTier p20 Apache\TomCat TZ:EST Have a form with a date (not date time) field. User enters the date 11/01/2007. When they save the record the MidTier is changing the date to 10/31/2007. I was not able to find any way of setting 11/1/2007 in that field. Also, if I enter the date as "11/1/2007 4:00:00 PM" it puts 11/0/2007 as the date. Anybody else seeing this scenario? Thank you Frank __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ == Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession. == __20060125___This posting was submitted with HTML in it___ __20060
Re: Possible DST Issue
Michelle, I am not aware of any bug defect with this. Since this "bug" will go away in 3 days anyways I hadn't planned on submitting a bug report. BTW, because of the nature of dates and time changes, moving forward I plan to always set dates to character fields before sending to SQL. This way, it shouldn't matter when the time changes. BTW #2, I recently read somewhere online that the Act that changed DST time in the US has a clause that allows Congress to revert back to the original DST time if they want to. When/if that happens then ARS, Java, OS's and other programs will need to be modified once again. T-Shirt idea: Just say 'No' to Daylight Saving Time Stephen Remedy Skilled Professional From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Michelle L Sent: Friday, November 02, 2007 9:57 AM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue ** Hi, Stephen: Thank you for the workaround and passing this along to the masses. Is there already a defect id for this? Thanks, Michelle "Heider, Stephen" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 11/02/2007 07:37 AM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Possible DST Issue ** Just wanted to pass this along... ARS 6.3 p22 (server, mid-tier, user tool), SQL Server 2000 (all patches), Windows Server 2003 (all patches). When passing a date in a date field within an active link to a Set Fields SQL User Defined Function Remedy changes the date to the previous day. This only occurs for dates starting this last Sunday through this coming Sunday. The work-around is to set the date field to a tmp character field first, then pass the tmp character field to the SQL user defined function. HTH Stephen Remedy Skilled Professional From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Thursday, November 01, 2007 5:09 PM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue Wow! That's weird. Does that happen from the native client too? Just for information purposes - what if you save it on the mid tier and then view the record from the mid-tier? What is the date displayed as? Also if you save from the native client does it display it correctly on the mid-tier? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Suwanski, Ron Sent: Thursday, November 01, 2007 4:25 PM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue ** Yes I saw it too.. but it was only for 11/1/2007. If you try 11/2/2007 it is fine.. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Frank Caruso Sent: Thursday, November 01, 2007 12:51 PM To: arslist@ARSLIST.ORG Subject: Possible DST Issue ** ARS 6.3 p20 Solairs\Sybase MidTier p20 Apache\TomCat TZ:EST Have a form with a date (not date time) field. User enters the date 11/01/2007. When they save the record the MidTier is changing the date to 10/31/2007. I was not able to find any way of setting 11/1/2007 in that field. Also, if I enter the date as "11/1/2007 4:00:00 PM" it puts 11/0/2007 as the date. Anybody else seeing this scenario? Thank you Frank __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ == Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession. == __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Possible DST Issue
Hi, Stephen: Thank you for the workaround and passing this along to the masses. Is there already a defect id for this? Thanks, Michelle "Heider, Stephen" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 11/02/2007 07:37 AM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: Possible DST Issue ** Just wanted to pass this along? ARS 6.3 p22 (server, mid-tier, user tool), SQL Server 2000 (all patches), Windows Server 2003 (all patches). When passing a date in a date field within an active link to a Set Fields SQL User Defined Function Remedy changes the date to the previous day. This only occurs for dates starting this last Sunday through this coming Sunday. The work-around is to set the date field to a tmp character field first, then pass the tmp character field to the SQL user defined function. HTH Stephen Remedy Skilled Professional From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Thursday, November 01, 2007 5:09 PM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue Wow! That's weird. Does that happen from the native client too? Just for information purposes - what if you save it on the mid tier and then view the record from the mid-tier? What is the date displayed as? Also if you save from the native client does it display it correctly on the mid-tier? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Suwanski, Ron Sent: Thursday, November 01, 2007 4:25 PM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue ** Yes I saw it too.. but it was only for 11/1/2007. If you try 11/2/2007 it is fine.. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Frank Caruso Sent: Thursday, November 01, 2007 12:51 PM To: arslist@ARSLIST.ORG Subject: Possible DST Issue ** ARS 6.3 p20 Solairs\Sybase MidTier p20 Apache\TomCat TZ:EST Have a form with a date (not date time) field. User enters the date 11/01/2007. When they save the record the MidTier is changing the date to 10/31/2007. I was not able to find any way of setting 11/1/2007 in that field. Also, if I enter the date as "11/1/2007 4:00:00 PM" it puts 11/0/2007 as the date. Anybody else seeing this scenario? Thank you Frank __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ == Confidentiality Notice: The information contained in and transmitted with this communication is strictly confidential, is intended only for the use of the intended recipient, and is the property of Countrywide Financial Corporation or its affiliates and subsidiaries. If you are not the intended recipient, you are hereby notified that any use of the information contained in or transmitted with the communication or dissemination, distribution, or copying of this communication is strictly prohibited by law. If you have received this communication in error, please immediately return this communication to the sender and delete the original message and any copy of it in your possession. == ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Possible DST Issue
Just wanted to pass this along... ARS 6.3 p22 (server, mid-tier, user tool), SQL Server 2000 (all patches), Windows Server 2003 (all patches). When passing a date in a date field within an active link to a Set Fields SQL User Defined Function Remedy changes the date to the previous day. This only occurs for dates starting this last Sunday through this coming Sunday. The work-around is to set the date field to a tmp character field first, then pass the tmp character field to the SQL user defined function. HTH Stephen Remedy Skilled Professional From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Thursday, November 01, 2007 5:09 PM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue Wow! That's weird. Does that happen from the native client too? Just for information purposes - what if you save it on the mid tier and then view the record from the mid-tier? What is the date displayed as? Also if you save from the native client does it display it correctly on the mid-tier? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Suwanski, Ron Sent: Thursday, November 01, 2007 4:25 PM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue ** Yes I saw it too.. but it was only for 11/1/2007. If you try 11/2/2007 it is fine.. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Frank Caruso Sent: Thursday, November 01, 2007 12:51 PM To: arslist@ARSLIST.ORG Subject: Possible DST Issue ** ARS 6.3 p20 Solairs\Sybase MidTier p20 Apache\TomCat TZ:EST Have a form with a date (not date time) field. User enters the date 11/01/2007. When they save the record the MidTier is changing the date to 10/31/2007. I was not able to find any way of setting 11/1/2007 in that field. Also, if I enter the date as "11/1/2007 4:00:00 PM" it puts 11/0/2007 as the date. Anybody else seeing this scenario? Thank you Frank __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Possible DST Issue
Do keep in mind that this is the week where the change between the "old" DST and "new" DST for the U.S., Canada and other related countries is occurring. But that being said, the time should only be off by one hour were the issue a DST issue. You may, however, want to review the technical bulletins on DST just in case to ensure you're patched properly from both an AR System and Operating System viewpoint. http://www.bmc.com/supportu/documents/87/90/68790/68790.pdf -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. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Thursday, November 01, 2007 2:09 PM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue ** Wow! That's weird. Does that happen from the native client too? Just for information purposes - what if you save it on the mid tier and then view the record from the mid-tier? What is the date displayed as? Also if you save from the native client does it display it correctly on the mid-tier? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Suwanski, Ron Sent: Thursday, November 01, 2007 4:25 PM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue ** Yes I saw it too.. but it was only for 11/1/2007. If you try 11/2/2007 it is fine.. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Frank Caruso Sent: Thursday, November 01, 2007 12:51 PM To: arslist@ARSLIST.ORG Subject: Possible DST Issue ** ARS 6.3 p20 Solairs\Sybase MidTier p20 Apache\TomCat TZ:EST Have a form with a date (not date time) field. User enters the date 11/01/2007. When they save the record the MidTier is changing the date to 10/31/2007. I was not able to find any way of setting 11/1/2007 in that field. Also, if I enter the date as "11/1/2007 4:00:00 PM" it puts 11/0/2007 as the date. Anybody else seeing this scenario? Thank you Frank __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Possible DST Issue
Wow! That's weird. Does that happen from the native client too? Just for information purposes - what if you save it on the mid tier and then view the record from the mid-tier? What is the date displayed as? Also if you save from the native client does it display it correctly on the mid-tier? Joe -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Suwanski, Ron Sent: Thursday, November 01, 2007 4:25 PM To: arslist@ARSLIST.ORG Subject: Re: Possible DST Issue ** Yes I saw it too.. but it was only for 11/1/2007. If you try 11/2/2007 it is fine.. -- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Frank Caruso Sent: Thursday, November 01, 2007 12:51 PM To: arslist@ARSLIST.ORG Subject: Possible DST Issue ** ARS 6.3 p20 Solairs\Sybase MidTier p20 Apache\TomCat TZ:EST Have a form with a date (not date time) field. User enters the date 11/01/2007. When they save the record the MidTier is changing the date to 10/31/2007. I was not able to find any way of setting 11/1/2007 in that field. Also, if I enter the date as "11/1/2007 4:00:00 PM" it puts 11/0/2007 as the date. Anybody else seeing this scenario? Thank you Frank No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.17/1103 - Release Date: 11/1/2007 6:01 AM ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Possible DST Issue
Yes I saw it too.. but it was only for 11/1/2007. If you try 11/2/2007 it is fine.. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Frank Caruso Sent: Thursday, November 01, 2007 12:51 PM To: arslist@ARSLIST.ORG Subject: Possible DST Issue ** ARS 6.3 p20 Solairs\Sybase MidTier p20 Apache\TomCat TZ:EST Have a form with a date (not date time) field. User enters the date 11/01/2007. When they save the record the MidTier is changing the date to 10/31/2007. I was not able to find any way of setting 11/1/2007 in that field. Also, if I enter the date as "11/1/2007 4:00:00 PM" it puts 11/0/2007 as the date. Anybody else seeing this scenario? Thank you Frank __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Possible DST Issue
ARS 6.3 p20 Solairs\Sybase MidTier p20 Apache\TomCat TZ:EST Have a form with a date (not date time) field. User enters the date 11/01/2007. When they save the record the MidTier is changing the date to 10/31/2007. I was not able to find any way of setting 11/1/2007 in that field. Also, if I enter the date as "11/1/2007 4:00:00 PM" it puts 11/0/2007 as the date. Anybody else seeing this scenario? Thank you Frank ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Clarification on DST ending (U)
UNCLASSIFIED Thank you! Sandra Hennigan OSD Enterprise Remedy Administrator Office # 703-602-2525 x251 Apparently, there is nothing that cannot happen today. Mark Twain -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David Sent: Tuesday, October 02, 2007 10:57 AM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending (U) I am referring to the patches released for the DST fix that are documented in the following technical bulletins: http://www.bmc.com/supportu/documents/87/89/68789/68789.pdf http://www.bmc.com/supportu/documents/87/90/68790/68790.pdf Patch 021 is the recommended minimum patch version on AR System 6.03 that corrects the DST start/end event issue. 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:[EMAIL PROTECTED] On Behalf Of Hennigan, Sandra H CTR OSD-CIO Sent: Tuesday, October 02, 2007 7:18 AM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending (U) UNCLASSIFIED "The patch corrects on which day DST occurs/ends. It does not alter the behavior of the actual time gain/loss on the day of the change." Are you referring to Remedy's Patch 21, the Daylight Saving Time (DST) patch that was released in March 2007? Sandra Hennigan OSD Enterprise Remedy Administrator Office # 703-602-2525 x251 Apparently, there is nothing that cannot happen today. Mark Twain -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David Sent: Monday, October 01, 2007 3:58 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** The patch corrects on which day DST occurs/ends. It does not alter the behavior of the actual time gain/loss on the day of the change. -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. _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Howard Richter Sent: Monday, October 01, 2007 10:07 AM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** I thought this patch was to fix both sides of the time change. Howard On 10/1/07, Dudley, Joelie <[EMAIL PROTECTED]> wrote: I just want to make sure I understand this correctly. When DST ends the first weekend in November the clocks get turned back one hour, in the past this would cause escalation between 2-3 am to fire twice is this still the case? The patch back in the spring was only to change the timeframe of when it was to occurred, correct? Thanks in advance for the clarification. Joelie Dudley Application Developer 555 Walnut Street 7th Floor, Forum Place Harrisburg, PA 17110 Phone: (717) 772-8143 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" -- Howard Richter Remedy ServiceDesk Manager CedarCrestone Managed Services Center [EMAIL PROTECTED] __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" __ _ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" smime.p7s Description: S/MIME cryptographic signature
Re: Clarification on DST ending (U)
I am referring to the patches released for the DST fix that are documented in the following technical bulletins: http://www.bmc.com/supportu/documents/87/89/68789/68789.pdf http://www.bmc.com/supportu/documents/87/90/68790/68790.pdf Patch 021 is the recommended minimum patch version on AR System 6.03 that corrects the DST start/end event issue. 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:[EMAIL PROTECTED] On Behalf Of Hennigan, Sandra H CTR OSD-CIO Sent: Tuesday, October 02, 2007 7:18 AM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending (U) UNCLASSIFIED "The patch corrects on which day DST occurs/ends. It does not alter the behavior of the actual time gain/loss on the day of the change." Are you referring to Remedy's Patch 21, the Daylight Saving Time (DST) patch that was released in March 2007? Sandra Hennigan OSD Enterprise Remedy Administrator Office # 703-602-2525 x251 Apparently, there is nothing that cannot happen today. Mark Twain -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David Sent: Monday, October 01, 2007 3:58 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** The patch corrects on which day DST occurs/ends. It does not alter the behavior of the actual time gain/loss on the day of the change. -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. _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Howard Richter Sent: Monday, October 01, 2007 10:07 AM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** I thought this patch was to fix both sides of the time change. Howard On 10/1/07, Dudley, Joelie <[EMAIL PROTECTED]> wrote: I just want to make sure I understand this correctly. When DST ends the first weekend in November the clocks get turned back one hour, in the past this would cause escalation between 2-3 am to fire twice is this still the case? The patch back in the spring was only to change the timeframe of when it was to occurred, correct? Thanks in advance for the clarification. Joelie Dudley Application Developer 555 Walnut Street 7th Floor, Forum Place Harrisburg, PA 17110 Phone: (717) 772-8143 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" -- Howard Richter Remedy ServiceDesk Manager CedarCrestone Managed Services Center [EMAIL PROTECTED] __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Clarification on DST ending (U)
UNCLASSIFIED "The patch corrects on which day DST occurs/ends. It does not alter the behavior of the actual time gain/loss on the day of the change." Are you referring to Remedy's Patch 21, the Daylight Saving Time (DST) patch that was released in March 2007? Sandra Hennigan OSD Enterprise Remedy Administrator Office # 703-602-2525 x251 Apparently, there is nothing that cannot happen today. Mark Twain -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David Sent: Monday, October 01, 2007 3:58 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** The patch corrects on which day DST occurs/ends. It does not alter the behavior of the actual time gain/loss on the day of the change. -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. _ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Howard Richter Sent: Monday, October 01, 2007 10:07 AM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** I thought this patch was to fix both sides of the time change. Howard On 10/1/07, Dudley, Joelie <[EMAIL PROTECTED]> wrote: I just want to make sure I understand this correctly. When DST ends the first weekend in November the clocks get turned back one hour, in the past this would cause escalation between 2-3 am to fire twice is this still the case? The patch back in the spring was only to change the timeframe of when it was to occurred, correct? Thanks in advance for the clarification. Joelie Dudley Application Developer 555 Walnut Street 7th Floor, Forum Place Harrisburg, PA 17110 Phone: (717) 772-8143 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" -- Howard Richter Remedy ServiceDesk Manager CedarCrestone Managed Services Center [EMAIL PROTECTED] __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Clarification on DST ending
The patch corrects on which day DST occurs/ends. It does not alter the behavior of the actual time gain/loss on the day of the change. -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. From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Howard Richter Sent: Monday, October 01, 2007 10:07 AM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** I thought this patch was to fix both sides of the time change. Howard On 10/1/07, Dudley, Joelie <[EMAIL PROTECTED]> wrote: I just want to make sure I understand this correctly. When DST ends the first weekend in November the clocks get turned back one hour, in the past this would cause escalation between 2-3 am to fire twice is this still the case? The patch back in the spring was only to change the timeframe of when it was to occurred, correct? Thanks in advance for the clarification. Joelie Dudley Application Developer 555 Walnut Street 7th Floor, Forum Place Harrisburg, PA 17110 Phone: (717) 772-8143 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" -- Howard Richter Remedy ServiceDesk Manager CedarCrestone Managed Services Center [EMAIL PROTECTED] __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Clarification on DST ending
**
Thanks all. I believe we will just disable escalations for that hour on
the night of the change, as we do use the ITSM 6.0 apps and I really
don't want to customize all of them right now. I appreciate all the
insight and suggestions.
Thanks a lot everyone!
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Shellman, David
Sent: Monday, October 01, 2007 2:14 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
Joe,
This might not help. Part of what I've seen in the past is that a
duplicate pair of escalations are spawned. It might help to stop the
second one from triggering but depending on timing they might fire at
the same time.
We usually have to cycle the app to get rid of the dups.
Dave
_
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, October 01, 2007 2:06 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
Its a pretty rare exception so I'm not surprised its not handled. Its
not applicable to a lot of countries anyway, but considering the ARS was
primarily designed and used in the west, where use of DST is more
common, maybe its time they do include such exceptions in their workflow
where workflow based on time as in Escalations could stand impacted.
Honestly if Jolie hadn't pointed out her problem I wouldn't have thought
of that exception either.. not until an application was impacted..
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Shellman, David
Sent: Monday, October 01, 2007 1:57 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
It would be nice if we would have designed our escalation to run
that way here at TycoElectronics but we haven't. I doubt that the OOB
escalations execute that way either.
Good suggestion though.
Dave
_
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, October 01, 2007 1:54 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
Yes I understand the reason why its happening. I was suggesting
a workaround for it not to happen by time stamping the run time of the
escalation and having an inclusion on the run if condition to make sure
that the last time it has fired is greater than 1 or 2 hours as the case
may be so it fires the next time only on the next night, thus
eliminating the exception when the time is reset due to DST adjustments.
Cheers
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Shellman, David
Sent: Monday, October 01, 2007 1:48 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
Joe,
We've seen this behavior for years. It happens with
escalations that are set to fire in the 2:00 AM to 3:00 AM time frame.
I think it also happens with escalations that are just set to fire at
intervals.
Dave
_
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, October 01, 2007 1:41 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
Joelie,
A workaround could be having the escalation check for
the last time it fired, and not fire if it has already fired an hour or
2 ago. This would mean you would have to customize your form for having
the last time the escalation fired and setting that timestamp there and
fixing the run if condition on your escalation accordingly..
Cheers
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Shellman, David
Sent: Monday, October 01, 2007 1:17 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
Joelie,
I would say that it depends. A lot has to do with how
the system clock
is reset. In the past with systems where the system
clock is reset
immediately we often saw this happe
Re: Clarification on DST ending
Joe,
This might not help. Part of what I've seen in the past is that a
duplicate pair of escalations are spawned. It might help to stop the
second one from triggering but depending on timing they might fire at
the same time.
We usually have to cycle the app to get rid of the dups.
Dave
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, October 01, 2007 2:06 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
Its a pretty rare exception so I'm not surprised its not handled. Its
not applicable to a lot of countries anyway, but considering the ARS was
primarily designed and used in the west, where use of DST is more
common, maybe its time they do include such exceptions in their workflow
where workflow based on time as in Escalations could stand impacted.
Honestly if Jolie hadn't pointed out her problem I wouldn't have thought
of that exception either.. not until an application was impacted..
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Shellman, David
Sent: Monday, October 01, 2007 1:57 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
It would be nice if we would have designed our escalation to run
that way here at TycoElectronics but we haven't. I doubt that the OOB
escalations execute that way either.
Good suggestion though.
Dave
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, October 01, 2007 1:54 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
Yes I understand the reason why its happening. I was suggesting
a workaround for it not to happen by time stamping the run time of the
escalation and having an inclusion on the run if condition to make sure
that the last time it has fired is greater than 1 or 2 hours as the case
may be so it fires the next time only on the next night, thus
eliminating the exception when the time is reset due to DST adjustments.
Cheers
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Shellman, David
Sent: Monday, October 01, 2007 1:48 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
Joe,
We've seen this behavior for years. It happens with
escalations that are set to fire in the 2:00 AM to 3:00 AM time frame.
I think it also happens with escalations that are just set to fire at
intervals.
Dave
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, October 01, 2007 1:41 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
Joelie,
A workaround could be having the escalation check for
the last time it fired, and not fire if it has already fired an hour or
2 ago. This would mean you would have to customize your form for having
the last time the escalation fired and setting that timestamp there and
fixing the run if condition on your escalation accordingly..
Cheers
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Shellman, David
Sent: Monday, October 01, 2007 1:17 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
Joelie,
I would say that it depends. A lot has to do with how
the system clock
is reset. In the past with systems where the system
clock is reset
immediately we often saw this happen. Some of our UNIX
servers were set
in a manner that the time change took effect over a
period of time and
we wouldn't see double escalations.
With 7.0.1 Patch 3, I'm seeing slightly different
behaviors with
escalations than I did with 6.3. Under 6.3 on SUN, when
we would set an
escalation to fire once a day, i
Re: Clarification on DST ending
Its a pretty rare exception so I'm not surprised its not handled. Its not
applicable to a lot of countries anyway, but considering the ARS was
primarily designed and used in the west, where use of DST is more common,
maybe its time they do include such exceptions in their workflow where
workflow based on time as in Escalations could stand impacted. Honestly if
Jolie hadn't pointed out her problem I wouldn't have thought of that
exception either.. not until an application was impacted..
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Shellman, David
Sent: Monday, October 01, 2007 1:57 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
It would be nice if we would have designed our escalation to run that way
here at TycoElectronics but we haven't. I doubt that the OOB escalations
execute that way either.
Good suggestion though.
Dave
--
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, October 01, 2007 1:54 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
Yes I understand the reason why its happening. I was suggesting a
workaround for it not to happen by time stamping the run time of the
escalation and having an inclusion on the run if condition to make sure that
the last time it has fired is greater than 1 or 2 hours as the case may be
so it fires the next time only on the next night, thus eliminating the
exception when the time is reset due to DST adjustments.
Cheers
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Shellman, David
Sent: Monday, October 01, 2007 1:48 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
Joe,
We've seen this behavior for years. It happens with escalations that
are set to fire in the 2:00 AM to 3:00 AM time frame. I think it also
happens with escalations that are just set to fire at intervals.
Dave
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza
Sent: Monday, October 01, 2007 1:41 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
**
Joelie,
A workaround could be having the escalation check for the last time it
fired, and not fire if it has already fired an hour or 2 ago. This would
mean you would have to customize your form for having the last time the
escalation fired and setting that timestamp there and fixing the run if
condition on your escalation accordingly..
Cheers
Joe D'Souza
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Shellman, David
Sent: Monday, October 01, 2007 1:17 PM
To: arslist@ARSLIST.ORG
Subject: Re: Clarification on DST ending
Joelie,
I would say that it depends. A lot has to do with how the system clock
is reset. In the past with systems where the system clock is reset
immediately we often saw this happen. Some of our UNIX servers were set
in a manner that the time change took effect over a period of time and
we wouldn't see double escalations.
With 7.0.1 Patch 3, I'm seeing slightly different behaviors with
escalations than I did with 6.3. Under 6.3 on SUN, when we would set an
escalation to fire once a day, it would fire as soon as we saved the
escalation. With 7.0.1, patch 003 on Windows, it doesn't fire
immediately but will trigger 24 hours later.
We may need to have someone from BMC/Remedy give us the true answer.
Dave
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Dudley, Joelie
Sent: Monday, October 01, 2007 12:38 PM
To: arslist@ARSLIST.ORG
Subject: Clarification on DST ending
I just want to make sure I understand this correctly. When DST ends the
first weekend in November the clocks get turned back one hour, in the
past this would cause escalation between 2-3 am to fire twice is this
still the case?
The patch back in the spring was only to change the timeframe of when it
was to occurred, correct?
Thanks in advance for the clarification.
Joelie Dudley
Application Developer
555 Walnut Street
7th Floor, Forum Place
Harrisburg, PA 17110
Phone: (717) 772-8143
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.13.36/1041 - Release Date: 10/1/2007
10:20 AM
Re: Clarification on DST ending
It would be nice if we would have designed our escalation to run that way here at TycoElectronics but we haven't. I doubt that the OOB escalations execute that way either. Good suggestion though. Dave From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Monday, October 01, 2007 1:54 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** Yes I understand the reason why its happening. I was suggesting a workaround for it not to happen by time stamping the run time of the escalation and having an inclusion on the run if condition to make sure that the last time it has fired is greater than 1 or 2 hours as the case may be so it fires the next time only on the next night, thus eliminating the exception when the time is reset due to DST adjustments. Cheers Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Shellman, David Sent: Monday, October 01, 2007 1:48 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** Joe, We've seen this behavior for years. It happens with escalations that are set to fire in the 2:00 AM to 3:00 AM time frame. I think it also happens with escalations that are just set to fire at intervals. Dave From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Monday, October 01, 2007 1:41 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** Joelie, A workaround could be having the escalation check for the last time it fired, and not fire if it has already fired an hour or 2 ago. This would mean you would have to customize your form for having the last time the escalation fired and setting that timestamp there and fixing the run if condition on your escalation accordingly.. Cheers Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Shellman, David Sent: Monday, October 01, 2007 1:17 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending Joelie, I would say that it depends. A lot has to do with how the system clock is reset. In the past with systems where the system clock is reset immediately we often saw this happen. Some of our UNIX servers were set in a manner that the time change took effect over a period of time and we wouldn't see double escalations. With 7.0.1 Patch 3, I'm seeing slightly different behaviors with escalations than I did with 6.3. Under 6.3 on SUN, when we would set an escalation to fire once a day, it would fire as soon as we saved the escalation. With 7.0.1, patch 003 on Windows, it doesn't fire immediately but will trigger 24 hours later. We may need to have someone from BMC/Remedy give us the true answer. Dave -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Dudley, Joelie Sent: Monday, October 01, 2007 12:38 PM To: arslist@ARSLIST.ORG Subject: Clarification on DST ending I just want to make sure I understand this correctly. When DST ends the first weekend in November the clocks get turned back one hour, in the past this would cause escalation between 2-3 am to fire twice is this still the case? The patch back in the spring was only to change the timeframe of when it was to occurred, correct? Thanks in advance for the clarification. Joelie Dudley Application Developer 555 Walnut Street 7th Floor, Forum Place Harrisburg, PA 17110 Phone: (717) 772-8143 __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Clarification on DST ending
Yes I understand the reason why its happening. I was suggesting a workaround for it not to happen by time stamping the run time of the escalation and having an inclusion on the run if condition to make sure that the last time it has fired is greater than 1 or 2 hours as the case may be so it fires the next time only on the next night, thus eliminating the exception when the time is reset due to DST adjustments. Cheers Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Shellman, David Sent: Monday, October 01, 2007 1:48 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** Joe, We've seen this behavior for years. It happens with escalations that are set to fire in the 2:00 AM to 3:00 AM time frame. I think it also happens with escalations that are just set to fire at intervals. Dave -- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Monday, October 01, 2007 1:41 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** Joelie, A workaround could be having the escalation check for the last time it fired, and not fire if it has already fired an hour or 2 ago. This would mean you would have to customize your form for having the last time the escalation fired and setting that timestamp there and fixing the run if condition on your escalation accordingly.. Cheers Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Shellman, David Sent: Monday, October 01, 2007 1:17 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending Joelie, I would say that it depends. A lot has to do with how the system clock is reset. In the past with systems where the system clock is reset immediately we often saw this happen. Some of our UNIX servers were set in a manner that the time change took effect over a period of time and we wouldn't see double escalations. With 7.0.1 Patch 3, I'm seeing slightly different behaviors with escalations than I did with 6.3. Under 6.3 on SUN, when we would set an escalation to fire once a day, it would fire as soon as we saved the escalation. With 7.0.1, patch 003 on Windows, it doesn't fire immediately but will trigger 24 hours later. We may need to have someone from BMC/Remedy give us the true answer. Dave -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Dudley, Joelie Sent: Monday, October 01, 2007 12:38 PM To: arslist@ARSLIST.ORG Subject: Clarification on DST ending I just want to make sure I understand this correctly. When DST ends the first weekend in November the clocks get turned back one hour, in the past this would cause escalation between 2-3 am to fire twice is this still the case? The patch back in the spring was only to change the timeframe of when it was to occurred, correct? Thanks in advance for the clarification. Joelie Dudley Application Developer 555 Walnut Street 7th Floor, Forum Place Harrisburg, PA 17110 Phone: (717) 772-8143 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.13.36/1041 - Release Date: 10/1/2007 10:20 AM ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Clarification on DST ending
Joe, We've seen this behavior for years. It happens with escalations that are set to fire in the 2:00 AM to 3:00 AM time frame. I think it also happens with escalations that are just set to fire at intervals. Dave From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Monday, October 01, 2007 1:41 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending ** Joelie, A workaround could be having the escalation check for the last time it fired, and not fire if it has already fired an hour or 2 ago. This would mean you would have to customize your form for having the last time the escalation fired and setting that timestamp there and fixing the run if condition on your escalation accordingly.. Cheers Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Shellman, David Sent: Monday, October 01, 2007 1:17 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending Joelie, I would say that it depends. A lot has to do with how the system clock is reset. In the past with systems where the system clock is reset immediately we often saw this happen. Some of our UNIX servers were set in a manner that the time change took effect over a period of time and we wouldn't see double escalations. With 7.0.1 Patch 3, I'm seeing slightly different behaviors with escalations than I did with 6.3. Under 6.3 on SUN, when we would set an escalation to fire once a day, it would fire as soon as we saved the escalation. With 7.0.1, patch 003 on Windows, it doesn't fire immediately but will trigger 24 hours later. We may need to have someone from BMC/Remedy give us the true answer. Dave -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Dudley, Joelie Sent: Monday, October 01, 2007 12:38 PM To: arslist@ARSLIST.ORG Subject: Clarification on DST ending I just want to make sure I understand this correctly. When DST ends the first weekend in November the clocks get turned back one hour, in the past this would cause escalation between 2-3 am to fire twice is this still the case? The patch back in the spring was only to change the timeframe of when it was to occurred, correct? Thanks in advance for the clarification. Joelie Dudley Application Developer 555 Walnut Street 7th Floor, Forum Place Harrisburg, PA 17110 Phone: (717) 772-8143 __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Clarification on DST ending
Joelie, A workaround could be having the escalation check for the last time it fired, and not fire if it has already fired an hour or 2 ago. This would mean you would have to customize your form for having the last time the escalation fired and setting that timestamp there and fixing the run if condition on your escalation accordingly.. Cheers Joe D'Souza -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Shellman, David Sent: Monday, October 01, 2007 1:17 PM To: arslist@ARSLIST.ORG Subject: Re: Clarification on DST ending Joelie, I would say that it depends. A lot has to do with how the system clock is reset. In the past with systems where the system clock is reset immediately we often saw this happen. Some of our UNIX servers were set in a manner that the time change took effect over a period of time and we wouldn't see double escalations. With 7.0.1 Patch 3, I'm seeing slightly different behaviors with escalations than I did with 6.3. Under 6.3 on SUN, when we would set an escalation to fire once a day, it would fire as soon as we saved the escalation. With 7.0.1, patch 003 on Windows, it doesn't fire immediately but will trigger 24 hours later. We may need to have someone from BMC/Remedy give us the true answer. Dave -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Dudley, Joelie Sent: Monday, October 01, 2007 12:38 PM To: arslist@ARSLIST.ORG Subject: Clarification on DST ending I just want to make sure I understand this correctly. When DST ends the first weekend in November the clocks get turned back one hour, in the past this would cause escalation between 2-3 am to fire twice is this still the case? The patch back in the spring was only to change the timeframe of when it was to occurred, correct? Thanks in advance for the clarification. Joelie Dudley Application Developer 555 Walnut Street 7th Floor, Forum Place Harrisburg, PA 17110 Phone: (717) 772-8143 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.13.36/1041 - Release Date: 10/1/2007 10:20 AM ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Clarification on DST ending
Joelie, I would say that it depends. A lot has to do with how the system clock is reset. In the past with systems where the system clock is reset immediately we often saw this happen. Some of our UNIX servers were set in a manner that the time change took effect over a period of time and we wouldn't see double escalations. With 7.0.1 Patch 3, I'm seeing slightly different behaviors with escalations than I did with 6.3. Under 6.3 on SUN, when we would set an escalation to fire once a day, it would fire as soon as we saved the escalation. With 7.0.1, patch 003 on Windows, it doesn't fire immediately but will trigger 24 hours later. We may need to have someone from BMC/Remedy give us the true answer. Dave -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Dudley, Joelie Sent: Monday, October 01, 2007 12:38 PM To: arslist@ARSLIST.ORG Subject: Clarification on DST ending I just want to make sure I understand this correctly. When DST ends the first weekend in November the clocks get turned back one hour, in the past this would cause escalation between 2-3 am to fire twice is this still the case? The patch back in the spring was only to change the timeframe of when it was to occurred, correct? Thanks in advance for the clarification. Joelie Dudley Application Developer 555 Walnut Street 7th Floor, Forum Place Harrisburg, PA 17110 Phone: (717) 772-8143 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: Clarification on DST ending
I thought this patch was to fix both sides of the time change. Howard On 10/1/07, Dudley, Joelie <[EMAIL PROTECTED]> wrote: > > I just want to make sure I understand this correctly. When DST ends the > first weekend in November the clocks get turned back one hour, in the > past this would cause escalation between 2-3 am to fire twice is this > still the case? > > The patch back in the spring was only to change the timeframe of when it > was to occurred, correct? > > Thanks in advance for the clarification. > > Joelie Dudley > Application Developer > 555 Walnut Street > 7th Floor, Forum Place > Harrisburg, PA 17110 > Phone: (717) 772-8143 > > > > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > the Answers Are" > -- Howard Richter Remedy ServiceDesk Manager CedarCrestone Managed Services Center [EMAIL PROTECTED] ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Clarification on DST ending
I just want to make sure I understand this correctly. When DST ends the first weekend in November the clocks get turned back one hour, in the past this would cause escalation between 2-3 am to fire twice is this still the case? The patch back in the spring was only to change the timeframe of when it was to occurred, correct? Thanks in advance for the clarification. Joelie Dudley Application Developer 555 Walnut Street 7th Floor, Forum Place Harrisburg, PA 17110 Phone: (717) 772-8143 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Issue
Yup, same thing happened here when we had the DST change in the US. Some of our users manually set their Time Zone in the User Tool so I had them clear it out and that fixed it. Darren Lau From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Nyall McCavitt Sent: Tuesday, March 27, 2007 8:57 AM To: arslist@ARSLIST.ORG Subject: Re: DST Issue Hi, Is the TimeZone parameter set on the Remedy User Tool? Check from Tools, Options then in the 'Locale' tab. I was caught out by this on Monday. Hope that this helps. Nyall Shellman, David wrote: ** I know this one has taken a beating with the time change in the US but has anyone seen issues resulting from time change in the UK over the weekend? We have an Active Link that's setting date and time into a character field (simulating Diary field functionality) with $TIMESTAMP$. We have at least one individual in the UK that has noted that $TIMESTAMP$ is off an hour. Time on the computer it's self is displaying correctly. Date/Time fields are displaying ok. He's using a 7.0.01 client against our 6.3 server. Dave Dave Shellman Phone: (717) 810-3687 Fax:(717) 810-2124 email: [EMAIL PROTECTED] tyco/Electronics A tyco International LTD Company MS 161-043 PO Box 3608 Harrisburg, PA 17105-3607 __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Issue - Solved
Sorry. I meant Time Zone set to GMT in the User Tool. Guess I need another cup of coffee. Dave From: Shellman, David Sent: Tuesday, March 27, 2007 12:06 PM To: arslist@ARSLIST.ORG Subject: RE: DST Issue - Solved Turns out the individuals had Locale set to GMT in the User tool. Dave From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shellman, David Sent: Tuesday, March 27, 2007 11:43 AM To: arslist@ARSLIST.ORG Subject: DST Issue ** I know this one has taken a beating with the time change in the US but has anyone seen issues resulting from time change in the UK over the weekend? We have an Active Link that's setting date and time into a character field (simulating Diary field functionality) with $TIMESTAMP$. We have at least one individual in the UK that has noted that $TIMESTAMP$ is off an hour. Time on the computer it's self is displaying correctly. Date/Time fields are displaying ok. He's using a 7.0.01 client against our 6.3 server. Dave Dave Shellman Phone: (717) 810-3687 Fax:(717) 810-2124 email: [EMAIL PROTECTED] tyco/Electronics A tyco International LTD Company MS 161-043 PO Box 3608 Harrisburg, PA 17105-3607 __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Issue - Solved
Turns out the individuals had Locale set to GMT in the User tool. Dave From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shellman, David Sent: Tuesday, March 27, 2007 11:43 AM To: arslist@ARSLIST.ORG Subject: DST Issue ** I know this one has taken a beating with the time change in the US but has anyone seen issues resulting from time change in the UK over the weekend? We have an Active Link that's setting date and time into a character field (simulating Diary field functionality) with $TIMESTAMP$. We have at least one individual in the UK that has noted that $TIMESTAMP$ is off an hour. Time on the computer it's self is displaying correctly. Date/Time fields are displaying ok. He's using a 7.0.01 client against our 6.3 server. Dave Dave Shellman Phone: (717) 810-3687 Fax:(717) 810-2124 email: [EMAIL PROTECTED] tyco/Electronics A tyco International LTD Company MS 161-043 PO Box 3608 Harrisburg, PA 17105-3607 __20060125___This posting was submitted with HTML in it___ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Issue
Title: DST Issue ** Hi, Is the TimeZone parameter set on the Remedy User Tool? Check from Tools, Options then in the 'Locale' tab. I was caught out by this on Monday. Hope that this helps. Nyall Shellman, David wrote: ** I know this one has taken a beating with the time change in the US but has anyone seen issues resulting from time change in the UK over the weekend? We have an Active Link that's setting date and time into a character field (simulating Diary field functionality) with $TIMESTAMP$. We have at least one individual in the UK that has noted that $TIMESTAMP$ is off an hour. Time on the computer it's self is displaying correctly. Date/Time fields are displaying ok. He's using a 7.0.01 client against our 6.3 server. Dave Dave Shellman Phone: (717) 810-3687 Fax: (717) 810-2124 email: [EMAIL PROTECTED] tyco/Electronics A tyco International LTD Company MS 161-043 PO Box 3608 Harrisburg, PA 17105-3607 __20060125___This posting was submitted with HTML in it___ __20060125___This posting was submitted with HTML in it___
DST Issue
I know this one has taken a beating with the time change in the US but has anyone seen issues resulting from time change in the UK over the weekend? We have an Active Link that's setting date and time into a character field (simulating Diary field functionality) with $TIMESTAMP$. We have at least one individual in the UK that has noted that $TIMESTAMP$ is off an hour. Time on the computer it's self is displaying correctly. Date/Time fields are displaying ok. He's using a 7.0.01 client against our 6.3 server. Dave Dave Shellman Phone: (717) 810-3687 Fax:(717) 810-2124 email: [EMAIL PROTECTED] tyco/Electronics A tyco International LTD Company MS 161-043 PO Box 3608 Harrisburg, PA 17105-3607 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Date/Time in a Table field on the Web Error
All, Ok, I know our Servers are DST compliant. I know my Client PC is DST compliant I've tested this with the following: ARS Server: 7.0.00 Patch 1 ARS Server: 7.0.01 Patch 1 Mid-Tier: 7.0.00 Patch 1 Mid-Tier: 7.0.01 Patch 1 User Tool: 7.0.00 Patch 1 User Tool: 7.0.01 Patch 1 Tests I've run: 1) Creating a ticket with both versions of the User tool listed above. RESULT: Displaying the Ticket in the User tool--->Time displays correctly 2) Creating a ticket with both versions of the User tool listed above. RESULT: Displaying the Ticket in the MID-Tier--->Time displays INCORRECTLY (off by 1 hour) 3) Creating a ticket from IE on the actual Server: RESULT: Displaying the Ticket in the User tool--->Time displays correctly 4) Creating a ticket from IE on the actual Server: RESULT: Displaying the Ticket in the MID-Tier--->Time displays INCORRECTLY (off by 1 hour) 5) Creating a ticket from IE on my PC: RESULT: Displaying the Ticket in the User tool--->Time displays correctly 6) Creating a ticket from IE on my PC: RESULT: Displaying the Ticket in the MID-Tier--->Time displays INCORRECTLY (off by 1 hour) It seems there is a problem with how the Mid-Tier is diplaying times from the database. Thanks, Matt -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Easter, David Sent: Monday, March 26, 2007 12:10 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error > I'm about to ask David Easter on the ARS List What version of the User tool is DST compliant, as I was using 7.0.00 Patch 1 No official testing was done of the AR System 7.0.00 patch 1 User Tool. Testing was only done with AR System 7.0.01 User Tool (both without and with patch 001). As per the FAQ in the tech bulletin, the User Tool does not have any code specific changes to be DST compliant, however the User Tool is affected by the Operating System's compliance for DST as outlined in the tech bulletin. Since no official testing was done, I don't know whether the 7.0.00 patch 1 User Tool is DST compliant - however it should be relatively easily for you to test that in your environment. I can say that AR System 7.0.01 User Tool patch 001 is definitely DST compliant (with the caveats about the OS dependency). 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:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Monday, March 26, 2007 8:41 AM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error Tony, AHHH she's on a 6.x, that might explain why it works for her. But yea, what you wrote below is the exact same thing I saw. I've upgraded our Mid-Tier now to 7.0.01 to see what the results are, and I'm about to ask David Easter on the ARS List What version of the User tool is DST compliant, as I was using 7.0.00 Patch 1, and the doc he sent is for 7.0.01. I've got a few things I want to try and see if they make any differences. I'll let yea know what I find and if I come up with a solution. Thanks, Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 26, 2007 10:36 AM To: arslist@ARSLIST.ORG; Matthew Perrault Subject: Re: DST Date/Time in a Table field on the Web Error Matthew - I'm guessing our issue is unique to a v7 server, as Michelle is on v6 ARS. I didn't have any TZ preference set. Just verified using another user account viewing the same data in Mid-Tier as in ARS and see the missing one hour on the web. The time/date fields are wrong in the results list, table fields and form. After setting my timezone in the preference form to to America/Chicago CST the dates (table/column/results) in mid-tier are correct. Hum... -tony -- Tony Worthington [EMAIL PROTECTED] 262-703-5911 Matthew Perrault <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 03/23/2007 04:09 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: DST Date/Time in a Table field on the Web Error Michelle, Thanks for the info, but that's not quite it. It's not a difference in the Results List and the Fields in the Form. It's the difference between what is shown in the USER tool and what is shown on the Web Pages. The other question I have is to take a look at your AR System User Preferences form. Do you have a Time Zone specified under the Locale tab? If you do Clear it, Clear y
Re: DST Date/Time in a Table field on the Web Error
> I'm about to ask David Easter on the ARS List What version of the User tool is DST compliant, as I was using 7.0.00 Patch 1 No official testing was done of the AR System 7.0.00 patch 1 User Tool. Testing was only done with AR System 7.0.01 User Tool (both without and with patch 001). As per the FAQ in the tech bulletin, the User Tool does not have any code specific changes to be DST compliant, however the User Tool is affected by the Operating System's compliance for DST as outlined in the tech bulletin. Since no official testing was done, I don't know whether the 7.0.00 patch 1 User Tool is DST compliant - however it should be relatively easily for you to test that in your environment. I can say that AR System 7.0.01 User Tool patch 001 is definitely DST compliant (with the caveats about the OS dependency). 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:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Monday, March 26, 2007 8:41 AM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error Tony, AHHH she's on a 6.x, that might explain why it works for her. But yea, what you wrote below is the exact same thing I saw. I've upgraded our Mid-Tier now to 7.0.01 to see what the results are, and I'm about to ask David Easter on the ARS List What version of the User tool is DST compliant, as I was using 7.0.00 Patch 1, and the doc he sent is for 7.0.01. I've got a few things I want to try and see if they make any differences. I'll let yea know what I find and if I come up with a solution. Thanks, Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 26, 2007 10:36 AM To: arslist@ARSLIST.ORG; Matthew Perrault Subject: Re: DST Date/Time in a Table field on the Web Error Matthew - I'm guessing our issue is unique to a v7 server, as Michelle is on v6 ARS. I didn't have any TZ preference set. Just verified using another user account viewing the same data in Mid-Tier as in ARS and see the missing one hour on the web. The time/date fields are wrong in the results list, table fields and form. After setting my timezone in the preference form to to America/Chicago CST the dates (table/column/results) in mid-tier are correct. Hum... -tony -- Tony Worthington [EMAIL PROTECTED] 262-703-5911 Matthew Perrault <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 03/23/2007 04:09 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: DST Date/Time in a Table field on the Web Error Michelle, Thanks for the info, but that's not quite it. It's not a difference in the Results List and the Fields in the Form. It's the difference between what is shown in the USER tool and what is shown on the Web Pages. The other question I have is to take a look at your AR System User Preferences form. Do you have a Time Zone specified under the Locale tab? If you do Clear it, Clear you IE cache, and then re-display the web pages. Do you get the same results? Thanks Matt -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lucero, Michelle - IST contractor Sent: Friday, March 23, 2007 3:57 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error If I understand you correctly, the issue is that there is a 1 hour difference between a date/time field on the form and the same field as displayed in the Results list. If so, we are not having this issue on Mid-Tier 7.0.01 Patch 1. This is a full windows 2003 environment with all windows patches applied. We didn't have to update any preferences, etc. Our environment is a little different. Mid-Tier 7.0.01 Patch 1 (Windows 2003/IIS 6/Java 1.6/Apache Tomcat 5.5) ARS 6.3 Patch 21 (Windows 2003/Remote SQL Server 2000) AR User 7.0.01 Patch 1 I had seen posts earlier this month regarding certain time zones. Something about a timezone record was missing or incorrect. We're in the US CDT zone. Hope that helps, Michelle -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 12:21 PM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patc
Re: DST Date/Time in a Table field on the Web Error
Tony, AHHH she's on a 6.x, that might explain why it works for her. But yea, what you wrote below is the exact same thing I saw. I've upgraded our Mid-Tier now to 7.0.01 to see what the results are, and I'm about to ask David Easter on the ARS List What version of the User tool is DST compliant, as I was using 7.0.00 Patch 1, and the doc he sent is for 7.0.01. I've got a few things I want to try and see if they make any differences. I'll let yea know what I find and if I come up with a solution. Thanks, Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 26, 2007 10:36 AM To: arslist@ARSLIST.ORG; Matthew Perrault Subject: Re: DST Date/Time in a Table field on the Web Error Matthew - I'm guessing our issue is unique to a v7 server, as Michelle is on v6 ARS. I didn't have any TZ preference set. Just verified using another user account viewing the same data in Mid-Tier as in ARS and see the missing one hour on the web. The time/date fields are wrong in the results list, table fields and form. After setting my timezone in the preference form to to America/Chicago CST the dates (table/column/results) in mid-tier are correct. Hum... -tony -- Tony Worthington [EMAIL PROTECTED] 262-703-5911 Matthew Perrault <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 03/23/2007 04:09 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: DST Date/Time in a Table field on the Web Error Michelle, Thanks for the info, but that's not quite it. It's not a difference in the Results List and the Fields in the Form. It's the difference between what is shown in the USER tool and what is shown on the Web Pages. The other question I have is to take a look at your AR System User Preferences form. Do you have a Time Zone specified under the Locale tab? If you do Clear it, Clear you IE cache, and then re-display the web pages. Do you get the same results? Thanks Matt -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lucero, Michelle - IST contractor Sent: Friday, March 23, 2007 3:57 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error If I understand you correctly, the issue is that there is a 1 hour difference between a date/time field on the form and the same field as displayed in the Results list. If so, we are not having this issue on Mid-Tier 7.0.01 Patch 1. This is a full windows 2003 environment with all windows patches applied. We didn't have to update any preferences, etc. Our environment is a little different. Mid-Tier 7.0.01 Patch 1 (Windows 2003/IIS 6/Java 1.6/Apache Tomcat 5.5) ARS 6.3 Patch 21 (Windows 2003/Remote SQL Server 2000) AR User 7.0.01 Patch 1 I had seen posts earlier this month regarding certain time zones. Something about a timezone record was missing or incorrect. We're in the US CDT zone. Hope that helps, Michelle -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 12:21 PM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt __
Re: DST Date/Time in a Table field on the Web Error
Matthew - I'm guessing our issue is unique to a v7 server, as Michelle is on v6 ARS. I didn't have any TZ preference set. Just verified using another user account viewing the same data in Mid-Tier as in ARS and see the missing one hour on the web. The time/date fields are wrong in the results list, table fields and form. After setting my timezone in the preference form to to America/Chicago CST the dates (table/column/results) in mid-tier are correct. Hum... -tony -- Tony Worthington [EMAIL PROTECTED] 262-703-5911 Matthew Perrault <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 03/23/2007 04:09 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: DST Date/Time in a Table field on the Web Error Michelle, Thanks for the info, but that's not quite it. It's not a difference in the Results List and the Fields in the Form. It's the difference between what is shown in the USER tool and what is shown on the Web Pages. The other question I have is to take a look at your AR System User Preferences form. Do you have a Time Zone specified under the Locale tab? If you do Clear it, Clear you IE cache, and then re-display the web pages. Do you get the same results? Thanks Matt -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lucero, Michelle - IST contractor Sent: Friday, March 23, 2007 3:57 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error If I understand you correctly, the issue is that there is a 1 hour difference between a date/time field on the form and the same field as displayed in the Results list. If so, we are not having this issue on Mid-Tier 7.0.01 Patch 1. This is a full windows 2003 environment with all windows patches applied. We didn't have to update any preferences, etc. Our environment is a little different. Mid-Tier 7.0.01 Patch 1 (Windows 2003/IIS 6/Java 1.6/Apache Tomcat 5.5) ARS 6.3 Patch 21 (Windows 2003/Remote SQL Server 2000) AR User 7.0.01 Patch 1 I had seen posts earlier this month regarding certain time zones. Something about a timezone record was missing or incorrect. We're in the US CDT zone. Hope that helps, Michelle -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 12:21 PM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" CONFIDENTIALITY NOTICE: This is a transmission from Kohl's Department Stores, Inc. and may contain information which is confidential and proprietary. If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is ex
Re: DST Date/Time in a Table field on the Web Error
Michelle, Yes that helps. Our Users don't have a preference record either. I just upgraded our Mid-Tier on Dev to 7.0.01 Patch 1. Took a look at my test record on the web and it still didn't show correctly. But this could be because I upgraded the Mid-Tier after the DST change, and the entry was created after the DST change but before I upgraded the mid-tier. I'm going through that document David Easter sent out: http://www.bmc.com/supportu/documents/87/89/68789/68789.pdf Thanks, Matt -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lucero, Michelle - IST contractor Sent: Friday, March 23, 2007 4:44 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error Hi, Matt: Thanks for clarifying. I double-checked the same entry on the BMC Remedy User Tool 7.0.01 Patch 1 and Mid-Tier 7.0.01 Patch 1. The date/time fields match. And nope, I don't have a Time zone listed under the locale tab. Most of our users do not have a preference record. Hope that helps, Michelle -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 4:10 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error Michelle, Thanks for the info, but that's not quite it. It's not a difference in the Results List and the Fields in the Form. It's the difference between what is shown in the USER tool and what is shown on the Web Pages. The other question I have is to take a look at your AR System User Preferences form. Do you have a Time Zone specified under the Locale tab? If you do Clear it, Clear you IE cache, and then re-display the web pages. Do you get the same results? Thanks Matt -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lucero, Michelle - IST contractor Sent: Friday, March 23, 2007 3:57 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error If I understand you correctly, the issue is that there is a 1 hour difference between a date/time field on the form and the same field as displayed in the Results list. If so, we are not having this issue on Mid-Tier 7.0.01 Patch 1. This is a full windows 2003 environment with all windows patches applied. We didn't have to update any preferences, etc. Our environment is a little different. Mid-Tier 7.0.01 Patch 1 (Windows 2003/IIS 6/Java 1.6/Apache Tomcat 5.5) ARS 6.3 Patch 21 (Windows 2003/Remote SQL Server 2000) AR User 7.0.01 Patch 1 I had seen posts earlier this month regarding certain time zones. Something about a timezone record was missing or incorrect. We're in the US CDT zone. Hope that helps, Michelle -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 12:21 PM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or
Re: DST Date/Time in a Table field on the Web Error
Hi, Matt: Thanks for clarifying. I double-checked the same entry on the BMC Remedy User Tool 7.0.01 Patch 1 and Mid-Tier 7.0.01 Patch 1. The date/time fields match. And nope, I don't have a Time zone listed under the locale tab. Most of our users do not have a preference record. Hope that helps, Michelle -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 4:10 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error Michelle, Thanks for the info, but that's not quite it. It's not a difference in the Results List and the Fields in the Form. It's the difference between what is shown in the USER tool and what is shown on the Web Pages. The other question I have is to take a look at your AR System User Preferences form. Do you have a Time Zone specified under the Locale tab? If you do Clear it, Clear you IE cache, and then re-display the web pages. Do you get the same results? Thanks Matt -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lucero, Michelle - IST contractor Sent: Friday, March 23, 2007 3:57 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error If I understand you correctly, the issue is that there is a 1 hour difference between a date/time field on the form and the same field as displayed in the Results list. If so, we are not having this issue on Mid-Tier 7.0.01 Patch 1. This is a full windows 2003 environment with all windows patches applied. We didn't have to update any preferences, etc. Our environment is a little different. Mid-Tier 7.0.01 Patch 1 (Windows 2003/IIS 6/Java 1.6/Apache Tomcat 5.5) ARS 6.3 Patch 21 (Windows 2003/Remote SQL Server 2000) AR User 7.0.01 Patch 1 I had seen posts earlier this month regarding certain time zones. Something about a timezone record was missing or incorrect. We're in the US CDT zone. Hope that helps, Michelle -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 12:21 PM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Date/Time in a Table field on the Web Error
Michelle, Thanks for the info, but that's not quite it. It's not a difference in the Results List and the Fields in the Form. It's the difference between what is shown in the USER tool and what is shown on the Web Pages. The other question I have is to take a look at your AR System User Preferences form. Do you have a Time Zone specified under the Locale tab? If you do Clear it, Clear you IE cache, and then re-display the web pages. Do you get the same results? Thanks Matt -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Lucero, Michelle - IST contractor Sent: Friday, March 23, 2007 3:57 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error If I understand you correctly, the issue is that there is a 1 hour difference between a date/time field on the form and the same field as displayed in the Results list. If so, we are not having this issue on Mid-Tier 7.0.01 Patch 1. This is a full windows 2003 environment with all windows patches applied. We didn't have to update any preferences, etc. Our environment is a little different. Mid-Tier 7.0.01 Patch 1 (Windows 2003/IIS 6/Java 1.6/Apache Tomcat 5.5) ARS 6.3 Patch 21 (Windows 2003/Remote SQL Server 2000) AR User 7.0.01 Patch 1 I had seen posts earlier this month regarding certain time zones. Something about a timezone record was missing or incorrect. We're in the US CDT zone. Hope that helps, Michelle -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 12:21 PM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Date/Time in a Table field on the Web Error
All, Just finished upgrading our Mid-Tier to 7.0.01 Patch 001 200701091113 And the problem still exists. Also, something else I found interesting which raises more questions: If you specify the TZ in your AR User Preferences, Clear your IE's History/Cookies/Cache, and load the form, the times come up correctly. Yet if we clear the TZ on the AR User Preferences form (or leave it clear) it shows up off by an hour. So now I have these questions: 1) How does the Mid-Tier choose to load/display Date/Times? Does it first look for the TZ on the User Preferences form and if it doesn't find one, pull the TZ from the server/Mid-Tier? If that is the case, then it should show the same value as when I specify my User Preferences TZ value to be America/Chicago as when the setting on my User Preferences record is blank (this is because the Server is also Central Time. Thanks, Matt From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Ben Cantatore Sent: Friday, March 23, 2007 2:38 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error ** I have this issue as well. I'm working with support, so far we've edited: /opt/apache-tomcat-5.5.20/webapps/arsys/resources/standard/javascript/ti mezone/America_Detroit.js /opt/apache-tomcat-5.5.20/webapps/arsys/shared/TimezoneFinder.js changing values in these files, but hasn't corrected the issue. Tony Worthington <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 03/23/2007 02:47 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: DST Date/Time in a Table field on the Web Error I wish that were true. I am at Mid-Tier 7.0.1 p001 here and am experiencing the time shift reported in the defect and by Matthew. I'll post results as Matthew and I further troubleshoot the issue. Does anyone on ARS+MT 7.0.1p1 *not* have this issue? -tony -- Tony Worthington [EMAIL PROTECTED] 262-703-5911 "Lammey, Peter A." <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 03/23/2007 12:55 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: DST Date/Time in a Table field on the Web Error According to what I have read regarding the DST patch fixes, you may need to upgrade your Mid Tier to 7.0.01 Patch 001. This Software bug is apparently resolved by Patch 001 on Mid Tier 7.0.01 Mid Tier: SW00255177 Mid-Tier (web) results vary in the search results panel & in the Form for the "Date/Time field" after US DST 2007 Start and End date Thanks Peter Lammey ESPN MIT Technical Services & Applications Management 860-766-4761 -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 1:21 PM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE o
Re: DST Date/Time in a Table field on the Web Error
> The Server team has patched the Server as well. > I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. You don't mention whether your clients have been patched for DST. Keep in mind that the Mid-Tier uses internal libraries to determine DST, but the client will use the operating system - or the 'C'-Run-Time (CRT) libraries if you have a specific time zone set as a preference (or have the TZ variable set in the OS). Check out a description of how this affects historical dates in the following tech bulletin for AR System 7.0.01: http://www.bmc.com/supportu/documents/87/89/68789/68789.pdf You may be encountering a similar issue where the client is performing an incorrect DST calculation and writing the information incorrectly to the DB. The Mid-Tier is properly displaying this incorrect information. When you view it again in the client, the client does the same "bad" conversion back to the correct time. The tech bulletin shows this process graphically... Perhaps not the issue you're seeing - but I would still check to see if your WUT client operating systems have been updated with a DST fix of some sort - either the Microsoft OS Registry patch or the updated CRT libraries if you're using TZ. -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:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 10:21 AM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Date/Time in a Table field on the Web Error
If I understand you correctly, the issue is that there is a 1 hour difference between a date/time field on the form and the same field as displayed in the Results list. If so, we are not having this issue on Mid-Tier 7.0.01 Patch 1. This is a full windows 2003 environment with all windows patches applied. We didn't have to update any preferences, etc. Our environment is a little different. Mid-Tier 7.0.01 Patch 1 (Windows 2003/IIS 6/Java 1.6/Apache Tomcat 5.5) ARS 6.3 Patch 21 (Windows 2003/Remote SQL Server 2000) AR User 7.0.01 Patch 1 I had seen posts earlier this month regarding certain time zones. Something about a timezone record was missing or incorrect. We're in the US CDT zone. Hope that helps, Michelle -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 12:21 PM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Date/Time in a Table field on the Web Error
I have this issue as well. I'm working with support, so far we've edited: /opt/apache-tomcat-5.5.20/webapps/arsys/resources/standard/javascript/timezone/America_Detroit.js /opt/apache-tomcat-5.5.20/webapps/arsys/shared/TimezoneFinder.js changing values in these files, but hasn't corrected the issue. Tony Worthington <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 03/23/2007 02:47 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: DST Date/Time in a Table field on the Web Error I wish that were true. I am at Mid-Tier 7.0.1 p001 here and am experiencing the time shift reported in the defect and by Matthew. I'll post results as Matthew and I further troubleshoot the issue. Does anyone on ARS+MT 7.0.1p1 *not* have this issue? -tony -- Tony Worthington [EMAIL PROTECTED] 262-703-5911 "Lammey, Peter A." <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 03/23/2007 12:55 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: DST Date/Time in a Table field on the Web Error According to what I have read regarding the DST patch fixes, you may need to upgrade your Mid Tier to 7.0.01 Patch 001. This Software bug is apparently resolved by Patch 001 on Mid Tier 7.0.01 Mid Tier: SW00255177 Mid-Tier (web) results vary in the search results panel & in the Form for the "Date/Time field" after US DST 2007 Start and End date Thanks Peter Lammey ESPN MIT Technical Services & Applications Management 860-766-4761 -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 1:21 PM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" CONFIDENTIALITY NOTICE: This is a transmission from Kohl's Department Stores, Inc. and may contain information which is confidential and proprietary. If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited. If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000. CAUTION: Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received. Kohl's reserves the right to monitor messages to or from authorized Kohl's Associates at any time without any further consent. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Date/Time in a Table field on the Web Error
I wish that were true. I am at Mid-Tier 7.0.1 p001 here and am experiencing the time shift reported in the defect and by Matthew. I'll post results as Matthew and I further troubleshoot the issue. Does anyone on ARS+MT 7.0.1p1 *not* have this issue? -tony -- Tony Worthington [EMAIL PROTECTED] 262-703-5911 "Lammey, Peter A." <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 03/23/2007 12:55 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject Re: DST Date/Time in a Table field on the Web Error According to what I have read regarding the DST patch fixes, you may need to upgrade your Mid Tier to 7.0.01 Patch 001. This Software bug is apparently resolved by Patch 001 on Mid Tier 7.0.01 Mid Tier: SW00255177 Mid-Tier (web) results vary in the search results panel & in the Form for the "Date/Time field" after US DST 2007 Start and End date Thanks Peter Lammey ESPN MIT Technical Services & Applications Management 860-766-4761 -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 1:21 PM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" CONFIDENTIALITY NOTICE: This is a transmission from Kohl's Department Stores, Inc. and may contain information which is confidential and proprietary. If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited. If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000. CAUTION: Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received. Kohl's reserves the right to monitor messages to or from authorized Kohl's Associates at any time without any further consent. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Date/Time in a Table field on the Web Error
All, Correction to Environment: Servers: Windows 2003 To answer Tony's questions below: The dates are off by 1 hour in the fields on the Base form as well. Thanks Matt -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Tony Worthington Sent: Friday, March 23, 2007 12:39 PM To: arslist@ARSLIST.ORG Subject: Re: DST Date/Time in a Table field on the Web Error I have the same issues with a similar environment. My issue applies to regular date/time fields via mid-tier as well. This is an ITSM7 QA system, so I haven't been too concerned and thought I missed something with the DST patches. Mostly same versions of ARS except Mid-Tier at 7.0.1 patch 001, Tomcat 5, Java 1.5.11, Win2k3 and Oracle 10.2.0.3.0 My dates are correct in the User Tool, and 1 hr behind on the web. I have also proceeded to re-check all of my DST work (ARS/OS/Java) and ensured nothing was missed. I've yet to go the route of setting TZ on the server and some of the other workarounds because I assumed since I followed BMC's whitepaper I was compliant. Interesting... and an issue that I need to resolve before "old" DST starts as I can imagine the issue will be gone, then rear its ugly head next year. Do all of your date/time appearances show this behavior or just dates in columns on joins? -tony -- Tony Worthington [EMAIL PROTECTED] 262-703-5911 Matthew Perrault <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" 03/23/2007 12:20 PM Please respond to arslist@ARSLIST.ORG To arslist@ARSLIST.ORG cc Subject DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" CONFIDENTIALITY NOTICE: This is a transmission from Kohl's Department Stores, Inc. and may contain information which is confidential and proprietary. If you are not the addressee, any disclosure, copying or distribution or use of the contents of this message is expressly prohibited. If you have received this transmission in error, please destroy it and notify us immediately at 262-703-7000. CAUTION: Internet and e-mail communications are Kohl's property and Kohl's reserves the right to retrieve and read any message created, sent and received. Kohl's reserves the right to monitor messages to or from authorized Kohl's Associates at any time without any further consent. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
Re: DST Date/Time in a Table field on the Web Error
According to what I have read regarding the DST patch fixes, you may need to upgrade your Mid Tier to 7.0.01 Patch 001. This Software bug is apparently resolved by Patch 001 on Mid Tier 7.0.01 Mid Tier: SW00255177 Mid-Tier (web) results vary in the search results panel & in the Form for the "Date/Time field" after US DST 2007 Start and End date Thanks Peter Lammey ESPN MIT Technical Services & Applications Management 860-766-4761 -Original Message- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Perrault Sent: Friday, March 23, 2007 1:21 PM To: arslist@ARSLIST.ORG Subject: DST Date/Time in a Table field on the Web Error All, Environment: AR User: 7.0.00 Patch 001 AR Server: 7.0.01 Patch 001 20070654 Mid-Tier: 7.0.00 Patch 001 200605201549 Java JRE: 1.4.2 Patch 13 IIS Windows 2K MS-SQL Ok, I've got a Join-form with a Date/Time field on it. I created a record on one of the base forms after the DST change/patches. When I open the Form in the User too, the Date/Time field shows the correct time. Yet when I open the Join Form on the Web the Date/Time field in the Results List table at the top shows the time off by an hour (1 Hour back). For Example the value in the field on the base form as well as the Join-form, when opened in the User Tool shows: 3/16/2007 10:32:44 AM When opened in the Web, the Column in the Results List table field shows: 3/16/2007 9:32:44 AM I've checked the Registry entries on the Server and they look good. The Mid-Tier runs on the same server as the ARS Service and the time on the Server looks good. The Server team has patched the Server as well. We've tested the Java Engine, and that appears ok, and DST compliant. I have added my TimeZone to my User Preferences, taken it off and that did not make any difference. The strange thing is, that records that were created before the DST time change show the correct Date/Time in both the User and Web. Records created AFTER the DST patch show the time off by an hour. The Mid-Tier and AR Server are both in the same time-zone as I am. So my questions are: 1) What could be causing this? 2) Is anyone else experiencing this? 3) Any Suggestions on how to fix this or where to look? Thanks, Matt ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
