Re: DST issues today RESOLVED

[Reiser, John J]

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

[Mueller, Doug]

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

[Reiser, John J]

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

[Grooms, Frederick W]

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"

Re: DST and Escalations

[LJ LongWing]

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

[David Sanders]

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.e-servicesuite.co.uk
 

 




  


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

[Shellman, David]

**
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"_

Re: DST Issues

[Kemes, Lisa]

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

[Kemes, Lisa]

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

[Shellman, David]

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

[Kemes, Lisa]

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

[Shellman, David]

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

[Grooms, Frederick W]

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

[Kemes, Lisa]

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

[Kemes, Lisa]

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

[Kemes, Lisa]

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

[David Sanders]

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

[Grooms, Frederick W]

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 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

[Kemes, Lisa]

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

[lisakemes]

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 in my DST testing in regards to business
> time.
>
> Environment:
> ARServer 7.0.01 patch 001
> SunOS 5.9 Generic_118558-26
> Mid-Tier 7.0.01 patch 001
> IBM WebSphere Application Server/6.0
> IBM Java 1

Re: DST Problem for Server in EMEA

[AMEY BHOSALE]

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

[Thomas Bean]

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

[AMEY BHOSALE]

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

[Thomas Bean]

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

Re: DST - Leap Year Issue with Date Only fields

[Thomas Bean]

# 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

[Shawn Stonequist]

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

[Michelle L]

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

[Michelle L]

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...

[Richard Copits]

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...

[Easter, David]

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
 
-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

[Evans.Randy]

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

[Randy Simon]

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

[Thomas Bean]

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

[Evans.Randy]

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"

Re: DST Issue

[LAU, DARREN (ATTASI)]

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

[Shellman, David]

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

[Shellman, David]

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

[Nyall McCavitt]

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___

Re: DST Date/Time in a Table field on the Web Error

[Matthew Perrault]

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

[Easter, David]

 
> 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

[Matthew Perrault]

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

[Tony Worthington]

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

[Matthew Perrault]

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

[Lucero, Michelle - IST contractor]

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

[Matthew Perrault]

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

[Matthew Perrault]

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

[Easter, David]

> 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

[Lucero, Michelle - IST contractor]

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

[Ben Cantatore]

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

[Tony Worthington]

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

[Matthew Perrault]

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

[Lammey, Peter A.]

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"

Re: DST Date/Time in a Table field on the Web Error

[Tony Worthington]

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"

Re: DST Invalid Times Question

[Lucero, Michelle - IST contractor]

Also, this occurs for any second Sunday in March before and after 2007. 

-Original Message-
From: Lucero, Michelle - IST contractor 
Sent: Tuesday, March 13, 2007 2:17 PM
To: 'arslist@ARSLIST.ORG'
Subject: RE: DST Invalid Times Question

Hi, Axton:

I assume that you are referring to ARS 7.0.01P1.

I do know that before we patched ARS Server 6.3 P18 to P21 that I ran a
small test in the Remedy User Tool 6.3 P20 and BMC Remedy User 7.0.01P1.
We have a little EPOCH <---> Real Time conversion button on a form.
Anytime between 03/11/2007 02:00:00 AM - 02:59:59 AM would yield the
value 3, as in 3 seconds.

When you back convert it, it comes out as 12/31/1969 06:00:03 PM.  Maybe
that's the conversion the server is doing.  I think you're Eastern
right?  So it is probably 12/31/1969 05:00:03 PM in your case.  Then
again, this little conversion is on the client side.

By the way, our error message that does popup when we convert back from
3 seconds says, "The date is out of the allowed range of 12/31/1969
through 1/18/2038.  Therefore, the calendar popup will be initialized to
the current date, and the time dropdown will be set to 12:00:00 AM."

...just something to look at.

Michelle

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Axton
Sent: Tuesday, March 13, 2007 1:36 PM
To: arslist@ARSLIST.ORG
Subject: DST Invalid Times Question

With 7.0.01p1, if a user submits a record with a date/time at or
between 3/11/07 2:00:00 am and 3/11 2:59:59 am, the following error is
returned:

Date is out of allowed range of 01/01/1970 - 01/19/2038 (GMT) for
Windows client. : "":  (ARERR 1889)

Can anyone confirm is this is how the system behaved prior to the DST
patches?  Any of you out there on 5.1.2 or unpatched care to test
entering a value of "3/11/2007 2:01:00 AM" in one of your DateTime
fields to let me know.

Thanks,
Axton Grams


___
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 Invalid Times Question

[Axton]

Reason I asked is because we have an integration where we get text
values such as "03/11/2007 02:00".  These are written to a character
field vi api.  We then perform a set field (filter) to a date/time
field from that char field.  The result is that 2:00am in the char
field returns 1:00am in the date/time field.  1:00am in the char field
also returns 1:00am in the date/time field.

I guess I was expecting that a filter set field action would have
yielded ARERR 1889, just like a user entry; or neither would have
returned an error.

Axton Grams

On 3/13/07, Lucero, Michelle - IST contractor
<[EMAIL PROTECTED]> wrote:

Hi, Axton:

I assume that you are referring to ARS 7.0.01P1.

I do know that before we patched ARS Server 6.3 P18 to P21 that I ran a
small test in the Remedy User Tool 6.3 P20 and BMC Remedy User 7.0.01P1.
We have a little EPOCH <---> Real Time conversion button on a form.
Anytime between 03/11/2007 02:00:00 AM - 02:59:59 AM would yield the
value 3, as in 3 seconds.

When you back convert it, it comes out as 12/31/1969 06:00:03 PM.  Maybe
that's the conversion the server is doing.  I think you're Eastern
right?  So it is probably 12/31/1969 05:00:03 PM in your case.  Then
again, this little conversion is on the client side.

By the way, our error message that does popup when we convert back from
3 seconds says, "The date is out of the allowed range of 12/31/1969
through 1/18/2038.  Therefore, the calendar popup will be initialized to
the current date, and the time dropdown will be set to 12:00:00 AM."

...just something to look at.

Michelle

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Axton
Sent: Tuesday, March 13, 2007 1:36 PM
To: arslist@ARSLIST.ORG
Subject: DST Invalid Times Question

With 7.0.01p1, if a user submits a record with a date/time at or
between 3/11/07 2:00:00 am and 3/11 2:59:59 am, the following error is
returned:

Date is out of allowed range of 01/01/1970 - 01/19/2038 (GMT) for
Windows client. : "":  (ARERR 1889)

Can anyone confirm is this is how the system behaved prior to the DST
patches?  Any of you out there on 5.1.2 or unpatched care to test
entering a value of "3/11/2007 2:01:00 AM" in one of your DateTime
fields to let me know.

Thanks,
Axton Grams


___
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 and TZupdater on 601 - worklog timestamp ok, other timestamps not - Resolved

[David Durling]

Solaris 9 has 113225-07 and 112874-37 installed, and the Window client 
PC has the OS DST patch -


but it turned out to be the java on my client PC that was the issue.  I 
was at 1.4.2, but not quite high enough to be compatible.


The tzupdater I was referring to was applied to our server, but I didn't 
really consider putting in on my client PC.


I'll probably point clients that have this issue to 
http://www.java.com/getjava or have them use their Java Console's update 
button, if they can find it, rather than have them try tzupdater on 
their client PCs (since I haven't had success just yet with that in my 
efforts).


Thanks for your responses -

David D.



Date: Tue, 13 Mar 2007 08:51:20 -0700
Reply-To: arslist@ARSLIST.ORG
Sender:   "Action Request System discussion list(ARSList)"
  
From: "Easter, David" <[EMAIL PROTECTED]>
Subject:  Re: DST and TZupdater on 601 - worklog timestamp ok,
  other timestamps not
In-Reply-To:  A<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"

And did you apply any OS patches to your Windows User Tool clients (or
allow them to be updated automatically by Windows Update)?

-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 Grooms, Frederick W
Sent: Tuesday, March 13, 2007 8:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST and TZupdater on 601 - worklog timestamp ok, other
timestamps not

You applied the Solaris 9 OS patch for DST? 


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of David Durling
Sent: Tuesday, March 13, 2007 10:35 AM
To: arslist@ARSLIST.ORG
Subject: DST and TZupdater on 601 - worklog timestamp ok, other
timestamps not

After applying the TZupdater patch from Sun, we noticed that the
timestamps for Work Log entries were correct, but timestamps for other
fields like the Create Date were still incorrect.

Dates in the Windows User Tool on a patched Windows PC are correct.



--
David Durling 706-542-0223
Enterprise IT Services [EMAIL PROTECTED]
University of Georgia

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers 
Are"

Re: DST Invalid Times Question

[Lucero, Michelle - IST contractor]

Hi, Axton:

I assume that you are referring to ARS 7.0.01P1.

I do know that before we patched ARS Server 6.3 P18 to P21 that I ran a
small test in the Remedy User Tool 6.3 P20 and BMC Remedy User 7.0.01P1.
We have a little EPOCH <---> Real Time conversion button on a form.
Anytime between 03/11/2007 02:00:00 AM - 02:59:59 AM would yield the
value 3, as in 3 seconds.

When you back convert it, it comes out as 12/31/1969 06:00:03 PM.  Maybe
that's the conversion the server is doing.  I think you're Eastern
right?  So it is probably 12/31/1969 05:00:03 PM in your case.  Then
again, this little conversion is on the client side.

By the way, our error message that does popup when we convert back from
3 seconds says, "The date is out of the allowed range of 12/31/1969
through 1/18/2038.  Therefore, the calendar popup will be initialized to
the current date, and the time dropdown will be set to 12:00:00 AM."

...just something to look at.

Michelle

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Axton
Sent: Tuesday, March 13, 2007 1:36 PM
To: arslist@ARSLIST.ORG
Subject: DST Invalid Times Question

With 7.0.01p1, if a user submits a record with a date/time at or
between 3/11/07 2:00:00 am and 3/11 2:59:59 am, the following error is
returned:

Date is out of allowed range of 01/01/1970 - 01/19/2038 (GMT) for
Windows client. : "":  (ARERR 1889)

Can anyone confirm is this is how the system behaved prior to the DST
patches?  Any of you out there on 5.1.2 or unpatched care to test
entering a value of "3/11/2007 2:01:00 AM" in one of your DateTime
fields to let me know.

Thanks,
Axton Grams


___
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 Invalid Times Question

[Grooms, Frederick W]

I tested this before and after the DST patches.   The User Tool uses the
OS to check the time so it will report an error during the DST window
(according to the Time Zone on your machine). 

For anyone in the US with an unpatched OS on your workstation try using
04/01/2007 2:01:00 AM.  You should get the error.

Fred

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Axton
Sent: Tuesday, March 13, 2007 1:36 PM
To: arslist@ARSLIST.ORG
Subject: DST Invalid Times Question

With 7.0.01p1, if a user submits a record with a date/time at or between
3/11/07 2:00:00 am and 3/11 2:59:59 am, the following error is
returned:

Date is out of allowed range of 01/01/1970 - 01/19/2038 (GMT) for
Windows client. : "":  (ARERR 1889)

Can anyone confirm is this is how the system behaved prior to the DST
patches?  Any of you out there on 5.1.2 or unpatched care to test
entering a value of "3/11/2007 2:01:00 AM" in one of your DateTime
fields to let me know.

Thanks,
Axton Grams

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the 
Answers Are"

Re: DST Invalid Times Question

[danaceau, Christopher M]

Axton, I've received that message before when trying to enter a
Date/Time value that fell within a DST window. 


-- 

Chris Danaceau
703-833-2459

The electronic mail message you have received and any files transmitted
with it are confidential and solely for the intended addressee(s)'s
attention. Do not divulge, copy, forward, or use the contents,
attachments, or information without permission of Fannie Mae.
Information contained in this message is provided solely for the purpose
stated in the message or its attachment(s) and must not be disclosed to
any third party or used for any other purpose without consent of Fannie
Mae. If you have received this message and/or any files transmitted with
it in error, please delete them from your system, destroy any hard
copies of them, and contact the sender. 



-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Axton
Sent: Tuesday, March 13, 2007 2:36 PM
To: arslist@ARSLIST.ORG
Subject: DST Invalid Times Question

With 7.0.01p1, if a user submits a record with a date/time at or between
3/11/07 2:00:00 am and 3/11 2:59:59 am, the following error is
returned:

Date is out of allowed range of 01/01/1970 - 01/19/2038 (GMT) for
Windows client. : "":  (ARERR 1889)

Can anyone confirm is this is how the system behaved prior to the DST
patches?  Any of you out there on 5.1.2 or unpatched care to test
entering a value of "3/11/2007 2:01:00 AM" in one of your DateTime
fields to let me know.

Thanks,
Axton Grams


___
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 Invalid Times Question

[ARSList]

In my UT (5.01.02 Patch 1254)

Date is out of allowed range of 01/01/1970 - 02/05/2036 for Windows
client. :  "3/11/2007 2:01:00 AM": Problem Occurred (ARERR 1889)

ARS 5.01.02 Patch 1245

Winnt 2000
SQL 2000

Nick Hromyak
State of California



-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Axton
Sent: Tuesday, March 13, 2007 11:36 AM
To: arslist@ARSLIST.ORG
Subject: DST Invalid Times Question

With 7.0.01p1, if a user submits a record with a date/time at or
between 3/11/07 2:00:00 am and 3/11 2:59:59 am, the following error is
returned:

Date is out of allowed range of 01/01/1970 - 01/19/2038 (GMT) for
Windows client. : "":  (ARERR 1889)

Can anyone confirm is this is how the system behaved prior to the DST
patches?  Any of you out there on 5.1.2 or unpatched care to test
entering a value of "3/11/2007 2:01:00 AM" in one of your DateTime
fields to let me know.

Thanks,
Axton Grams


___
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 and TZupdater on 601 - worklog timestamp ok, other timestamps not

[David Durling]

By the way, though it's implied in my post, I didn't specifically say 
that this is a midtier display issue -


I'm checking w/ our sys admins on the OS patch, though.

David D.


Date: Tue, 13 Mar 2007 10:42:58 -0500
Reply-To: arslist@ARSLIST.ORG
Sender:   "Action Request System discussion list(ARSList)"
  
From: "Grooms, Frederick W" <[EMAIL PROTECTED]>
Subject:  Re: DST and TZupdater on 601 - worklog timestamp ok,
  other timestamps not
In-Reply-To:  A<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"

You applied the Solaris 9 OS patch for DST? 


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of David Durling
Sent: Tuesday, March 13, 2007 10:35 AM
To: arslist@ARSLIST.ORG
Subject: DST and TZupdater on 601 - worklog timestamp ok, other
timestamps not

After applying the TZupdater patch from Sun, we noticed that the
timestamps for Work Log entries were correct, but timestamps for other
fields like the Create Date were still incorrect.

Dates in the Windows User Tool on a patched Windows PC are correct.

Is there something else that needs changin or updating, or did I
misunderstand the DST Technical Bulletin for 601? 
http://documents.bmc.com/supportu/documents/87/91/68791/68791.pdf


  The things mentioned were web services, export, & a couple of other
things we thought would not be big issues for us, but I do notice a
sentence that says, "...workflow processed on the BMC Remedy Mid Tier
might be one hour off..." on page 2, though I don't specifically listed
in 4 issues charted as problems for 6.0.1.

David D.

ARS 6.0.1 patch 1351, midtier patch 1353 Solaris 9, Oracle 9iR2, tomcat
4.1.30 with the tzupdate applied



--
David Durling 706-542-0223
Enterprise IT Services [EMAIL PROTECTED]
University of Georgia

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers 
Are"

Re: DST and TZupdater on 601 - worklog timestamp ok, other timestamps not

[Easter, David]

And did you apply any OS patches to your Windows User Tool clients (or
allow them to be updated automatically by Windows Update)?

-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 Grooms, Frederick W
Sent: Tuesday, March 13, 2007 8:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST and TZupdater on 601 - worklog timestamp ok, other
timestamps not

You applied the Solaris 9 OS patch for DST? 

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of David Durling
Sent: Tuesday, March 13, 2007 10:35 AM
To: arslist@ARSLIST.ORG
Subject: DST and TZupdater on 601 - worklog timestamp ok, other
timestamps not

After applying the TZupdater patch from Sun, we noticed that the
timestamps for Work Log entries were correct, but timestamps for other
fields like the Create Date were still incorrect.

Dates in the Windows User Tool on a patched Windows PC are correct.

Is there something else that needs changin or updating, or did I
misunderstand the DST Technical Bulletin for 601? 
http://documents.bmc.com/supportu/documents/87/91/68791/68791.pdf

  The things mentioned were web services, export, & a couple of other
things we thought would not be big issues for us, but I do notice a
sentence that says, "...workflow processed on the BMC Remedy Mid Tier
might be one hour off..." on page 2, though I don't specifically listed
in 4 issues charted as problems for 6.0.1.

David D.

ARS 6.0.1 patch 1351, midtier patch 1353 Solaris 9, Oracle 9iR2, tomcat
4.1.30 with the tzupdate applied

-- 
David Durling 706-542-0223
Enterprise IT Services [EMAIL PROTECTED]
University of Georgia


___
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 and TZupdater on 601 - worklog timestamp ok, other timestamps not

[Grooms, Frederick W]

You applied the Solaris 9 OS patch for DST? 

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of David Durling
Sent: Tuesday, March 13, 2007 10:35 AM
To: arslist@ARSLIST.ORG
Subject: DST and TZupdater on 601 - worklog timestamp ok, other
timestamps not

After applying the TZupdater patch from Sun, we noticed that the
timestamps for Work Log entries were correct, but timestamps for other
fields like the Create Date were still incorrect.

Dates in the Windows User Tool on a patched Windows PC are correct.

Is there something else that needs changin or updating, or did I
misunderstand the DST Technical Bulletin for 601? 
http://documents.bmc.com/supportu/documents/87/91/68791/68791.pdf

  The things mentioned were web services, export, & a couple of other
things we thought would not be big issues for us, but I do notice a
sentence that says, "...workflow processed on the BMC Remedy Mid Tier
might be one hour off..." on page 2, though I don't specifically listed
in 4 issues charted as problems for 6.0.1.

David D.

ARS 6.0.1 patch 1351, midtier patch 1353 Solaris 9, Oracle 9iR2, tomcat
4.1.30 with the tzupdate applied

-- 
David Durling 706-542-0223
Enterprise IT Services [EMAIL PROTECTED]
University of Georgia

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the 
Answers Are"

Re: DST Test Results on March 11th 8:00 AM

[Nall, Roger]

No problem. I just meant that my issue was resolved.

 

Thanks,

 

Roger A. Nall

Manager, OSSNMS Remedy

T-Mobile USA

Desk: 813-348-2556(New)

Cell: 973-652-6723

FAX: 813-348-2565

sf49fanv AIM IM

RogerNall   Yahoo IM

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Palmer
Sent: Monday, March 12, 2007 4:59 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

 

** 

Hi Roger  I removed RESOLVED because although your issue was taken
care others may have open issues.  Hope that was ok,

Susan

 

On 3/12/07, Nall, Roger <[EMAIL PROTECTED]> wrote: 

After applying this patch, http://support.microsoft.com/kb/932590 , all
is well. Thanks to everyone for their suggestions.

Regards,

Roger A. Nall
Manager, OSSNMS Remedy
T-Mobile USA
Desk: 813-348-2556(New)
Cell: 973-652-6723
FAX: 813-348-2565
sf49fanv AIM IM 
RogerNall   Yahoo IM


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Heider, Stephen
Sent: Monday, March 12, 2007 9:21 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

Another, or additional, method would be to run a Direct SQL command each

time users login (loads the main form)

UPDATE AR_System_User_Preference SET Time_Zone = NULL WHERE Submitter =
'$USER$'

This would take effect the next time the user logged in. I actually do
this with a stored procedure that sets a number of settings in the
preference form.  Users are allowed to change some settings in the User
Tool but there are some that I want every user to have.  This has
completely eliminated support calls for fixing User Tool settings. 

You could also simply Null out the field for all users at once using a
tool such as SQL Query Analyzer.

UPDATE AR_System_User_Preference SET Time_Zone = NULL

HTH

Stephen


___ 
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"


__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 Test Results on March 11th 8:00 AM

[Susan Palmer]

Hi Roger  I removed RESOLVED because although your issue was taken care
others may have open issues.  Hope that was ok,
Susan


On 3/12/07, Nall, Roger <[EMAIL PROTECTED]> wrote:


After applying this patch, http://support.microsoft.com/kb/932590, all
is well. Thanks to everyone for their suggestions.

Regards,

Roger A. Nall
Manager, OSSNMS Remedy
T-Mobile USA
Desk: 813-348-2556(New)
Cell: 973-652-6723
FAX: 813-348-2565
sf49fanv AIM IM
RogerNall   Yahoo IM


-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Heider, Stephen
Sent: Monday, March 12, 2007 9:21 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

Another, or additional, method would be to run a Direct SQL command each
time users login (loads the main form)

UPDATE AR_System_User_Preference SET Time_Zone = NULL WHERE Submitter =
'$USER$'

This would take effect the next time the user logged in. I actually do
this with a stored procedure that sets a number of settings in the
preference form.  Users are allowed to change some settings in the User
Tool but there are some that I want every user to have.  This has
completely eliminated support calls for fixing User Tool settings.

You could also simply Null out the field for all users at once using a
tool such as SQL Query Analyzer.

UPDATE AR_System_User_Preference SET Time_Zone = NULL

HTH

Stephen


___
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 Test Results on March 11th 8:00 AM

[Heider, Stephen]

Carey,

Good point.  Everyone here uses a preference server. Your approach would
work in either situation.


Stephen 

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Monday, March 12, 2007 11:19 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

Stephen,

That will only alter the TZ setting for users who use the preference
server. For those User Tool users who do not use a preference server
then their settings are in their local ar.ini file. And the method that
I suggested would work for those users as well as those that use a
preference server.

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.


On 3/12/07, Heider, Stephen <[EMAIL PROTECTED]> wrote:
> Another, or additional, method would be to run a Direct SQL command 
> each time users login (loads the main form)
>
> UPDATE AR_System_User_Preference SET Time_Zone = NULL WHERE Submitter 
> = '$USER$'
>
> This would take effect the next time the user logged in. I actually do

> this with a stored procedure that sets a number of settings in the 
> preference form.  Users are allowed to change some settings in the 
> User Tool but there are some that I want every user to have.  This has

> completely eliminated support calls for fixing User Tool settings.
>
> You could also simply Null out the field for all users at once using a

> tool such as SQL Query Analyzer.
>
> UPDATE AR_System_User_Preference SET Time_Zone = NULL
>
> HTH
>
> Stephen
>
> -Original Message-
> From: Action Request System discussion list(ARSList) 
> [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
> Sent: Monday, March 12, 2007 8:43 AM
> To: arslist@ARSLIST.ORG
> Subject: Re: DST Test Results on March 11th 8:00 AM
>
> Roger,
>
> We found that the User Tool must NOT have a TZ setting value for the 
> values to be correct for the 2007 DST range. That lack of a setting 
> however also makes the pre 2007 DST values display incorrectly too.
> (So pick your poison.)
>
>
> We added two active links (Only for the User Tool because our Mid-Tier
> v6.3 patch 21 appears to be ok with or without a client TZ setting.) 
> to our major forms that use a combination of the following workflow...
>
> AL #1:
> zTemp = $PROCESS$ PERFORM-ACTION-GET-PREFERENCE 20123
>
> AL #2:
> if zTemp != NULL
> --> Message "Your Time Zone setting was found to have a value. Please
> review the following information..."
>   Then we do a Run Process: PERFORM-ACTION-OPEN-URL new "http."
>   To open a quick PDF that we put together to show the user how to 
> clear the setting.
>
> We also tried to use the GET/SET preference commands, but they 
> appeared to not become effected for the User Tool until the user 
> logged out and back in. Sigh. But the user doing it via
> Tools-->Options did become effective immediately. So we opted to let
> the user set the setting.
>
> HTH
>
> --
> Carey Matthew Black
> Remedy Skilled Professional (RSP)
> ARS = Action Request System(Remedy)
>
> Love, then teach
> Solution = People + Process + Tools
> Fast, Accurate, Cheap Pick two.
>
>
> On 3/12/07, Nall, Roger <[EMAIL PROTECTED]> wrote:
> > **
> >
> >
> >
> > You are correct. However, I am the only one in my company using the 
> > AR
>
> > User Preference form. We are a Citrix shop and are not able to use 
> > the
>
> > AR User Preference form across the board until we upgrade to 7.01. 
> > It has to do with the way the preference value is stored in the
registry.
>
> > That being said, everyone else uses Citrix to launch Remedy which 
> > means they each have a centralized ar.ini file. I am at a loss as to
> how to proceed from here.
> > Should we remove the TZ values from the ini files and hope they 
> > don't reset them? Any ideas are most welcome.
> >
> >
> >
> > Thanks,
> >
> >
> >
> >
> > Roger A. Nall
> >
> > Manager, OSSNMS Remedy
> >
> > T-Mobile USA
> >
> > Desk: 813-348-2556(New)
> >
> > Cell: 973-652-6723
> >
> > FAX: 813-348-2565
> >
> > sf49fanv AIM IM
> >
> > RogerNall   Yahoo IM


___
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 Test Results on March 11th 8:00 AM

[Easter, David]

If you're on 6.03 and using the TZ values, then you'll need to obtain
the updated MSVCRT.DLL file from Microsoft.  This is described in the
technical bulletin for 6.03 found at:
 
http://www.bmc.com/supportu/documents/87/90/68790/68790.pdf
 
In a nutshell, if you don't use the TZ variable, then you go to the OS
registry for DST information.  If you use the TZ variable, then you go
to the Visual Studio libraries (a.k.a. the Microsoft 'C' Run Time
libraries or CRT).  The Visual Studio libraries have to be updated to
recognize the new 2007 rules.  Specifically, the KB article for
obtaining MSVCRT.DLL is:
http://support.microsoft.com/?id=932590

This MSFT CRT DLL library is appropriate for 6.03, 6.0.1 and 5.1.2.  The
7.0.01 MSFT CRT DLL libraries (msvcp71.dll and msvcr71.dll) can be
obtained by contacting BMC support.
 
These libraries are also year-aware, so they will address the issues
with historical dates described in the technical bulletin.  
 
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.
 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Nall, Roger
Sent: Monday, March 12, 2007 12:41 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM


** 

You are correct. However, I am the only one in my company using the AR
User Preference form. We are a Citrix shop and are not able to use the
AR User Preference form across the board until we upgrade to 7.01. It
has to do with the way the preference value is stored in the registry.
That being said, everyone else uses Citrix to launch Remedy which means
they each have a centralized ar.ini file. I am at a loss as to how to
proceed from here. Should we remove the TZ values from the ini files and
hope they don't reset them? Any ideas are most welcome.

 

Thanks,

 

Roger A. Nall

Manager, OSSNMS Remedy

T-Mobile USA

Desk: 813-348-2556(New)

Cell: 973-652-6723

FAX: 813-348-2565

sf49fanv AIM IM

RogerNall   Yahoo IM

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas Bean
Sent: Monday, March 12, 2007 1:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

 

Roger,

You might check to make sure you don't have the time zone set in the AR
User Preferences form.  That could cause the times to be displayed one
hour off.  As long as Windows is patched, the User tool should pull the
correct time zone settings from the OS.

 

--Thomas

 

- Original Message - 

From: Nall, Roger <mailto:[EMAIL PROTECTED]>  

Newsgroups: gmane.comp.crm.arsystem.general

To: arslist@ARSLIST.ORG 

Sent: Sunday, March 11, 2007 13:55

Subject: Re: DST Test Results on March 11th 8:00 AM

 

** 

I did nothing as well but all of my times are off by one hour.
According to BMC this should not have happened. I do not use the
mid-tier. I am on ARS 6.03, patch 16, windows2k, sql2k. All OS were
patched. Has anyone else seen this behavior?

Thanks,


Roger Nall
Manager, OSSNMS  Remedy
T-Mobile, USA
Desk: 813-348-2556(NEW)
Mobile:973-652-6723
FAX: 813-348-2565
Sf49fanv  AIMIM
RogerNall. Yahoo IM

Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Sanford, Claire
[mailto:[EMAIL PROTECTED]
Sent:   Sunday, March 11, 2007 10:29 AM Pacific Standard Time
To: arslist@ARSLIST.ORG
Subject:Re: DST Test Results on March 11th 8:00 AM

Ok, so I did NOTHING.  I made no changes, added no patches (I am
sure
this will bite me some time down the road) and everything worked
as it
was supposed to work.



The time changed on the server, the time changed in Remedy, the
time was
correct on my tickets and the escalations worked as they should
have.



The end result...  I lose an hour of sleep in the morning, the
dogs gain
an hour of daylight for the park after work!



Claire





From: Action Request System discussion list(ARSList)
__20060125___This posting was submitted with
HTML in it___

__20060125___This posting was submitted with HTML in
it___ __200601

Re: DST Test Results on March 11th 8:00 AM

[Carey Matthew Black]

Stephen,

That will only alter the TZ setting for users who use the preference
server. For those User Tool users who do not use a preference server
then their settings are in their local ar.ini file. And the method
that I suggested would work for those users as well as those that use
a preference server.

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.


On 3/12/07, Heider, Stephen <[EMAIL PROTECTED]> wrote:

Another, or additional, method would be to run a Direct SQL command each
time users login (loads the main form)

UPDATE AR_System_User_Preference SET Time_Zone = NULL WHERE Submitter =
'$USER$'

This would take effect the next time the user logged in. I actually do
this with a stored procedure that sets a number of settings in the
preference form.  Users are allowed to change some settings in the User
Tool but there are some that I want every user to have.  This has
completely eliminated support calls for fixing User Tool settings.

You could also simply Null out the field for all users at once using a
tool such as SQL Query Analyzer.

UPDATE AR_System_User_Preference SET Time_Zone = NULL

HTH

Stephen

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Monday, March 12, 2007 8:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

Roger,

We found that the User Tool must NOT have a TZ setting value for the
values to be correct for the 2007 DST range. That lack of a setting
however also makes the pre 2007 DST values display incorrectly too.
(So pick your poison.)


We added two active links (Only for the User Tool because our Mid-Tier
v6.3 patch 21 appears to be ok with or without a client TZ setting.) to
our major forms that use a combination of the following workflow...

AL #1:
zTemp = $PROCESS$ PERFORM-ACTION-GET-PREFERENCE 20123

AL #2:
if zTemp != NULL
--> Message "Your Time Zone setting was found to have a value. Please
review the following information..."
  Then we do a Run Process: PERFORM-ACTION-OPEN-URL new "http."
  To open a quick PDF that we put together to show the user how to clear
the setting.

We also tried to use the GET/SET preference commands, but they appeared
to not become effected for the User Tool until the user logged out and
back in. Sigh. But the user doing it via
Tools-->Options did become effective immediately. So we opted to let
the user set the setting.

HTH

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.


On 3/12/07, Nall, Roger <[EMAIL PROTECTED]> wrote:
> **
>
>
>
> You are correct. However, I am the only one in my company using the AR

> User Preference form. We are a Citrix shop and are not able to use the

> AR User Preference form across the board until we upgrade to 7.01. It
> has to do with the way the preference value is stored in the registry.

> That being said, everyone else uses Citrix to launch Remedy which
> means they each have a centralized ar.ini file. I am at a loss as to
how to proceed from here.
> Should we remove the TZ values from the ini files and hope they don't
> reset them? Any ideas are most welcome.
>
>
>
> Thanks,
>
>
>
>
> Roger A. Nall
>
> Manager, OSSNMS Remedy
>
> T-Mobile USA
>
> Desk: 813-348-2556(New)
>
> Cell: 973-652-6723
>
> FAX: 813-348-2565
>
> sf49fanv AIM IM
>
> RogerNall   Yahoo IM


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers 
Are"

Re: DST Test Results on March 11th 8:00 AM

[Opela, Gary L Contr OC-ALC/ITMA]

Carey, thanks for the suggestion. I checked and for some reason my
servers were still at CST instead of CDT. I had to do the trick of
changing the TZ then changing it back to get it to pick up the change
from Standard to Daylight.

I thought that would fix it, but it didn't. I'm still off by an hour,
and both my client and my server are at CDT.

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Monday, March 12, 2007 8:17 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

Gary,


Assuming that your 'Create Time' field is a "Time Field" not a
"Date/Time Field". I am talking data types here, not display values.

Just a guess... but I think your client is in a different timezone
than the ARS server?

The "Date/Time Field" values should be localized however the "Time
Field" will not be localized. (By design of those field types.)

-- 
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.


On 3/12/07, Opela, Gary L Contr OC-ALC/ITMA
<[EMAIL PROTECTED]> wrote:
> **
>
>
>
> Okay, so here is a weird one
>
>
>
> On one of our servers, on one application, we have a Create Date field
(this
> standard core field) and a create time field. The create time field is
set
> to $TIME$ by a filter on submit.
>
>
>
> The create time and create date fields are off from each other by an
hour.
> The Create Date field shows the correct time, 7:30, and the Create
Time
> field shows 6:30...
>
>
>
> Help


___
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 Test Results on March 11th 8:00 AM

[Opela, Gary L Contr OC-ALC/ITMA]

Carey, I saw some other people had said to reset the TZ variable on the
server. Do you think this might help to correct the issue?

Thanks,

Gary

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Monday, March 12, 2007 8:17 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

Gary,


Assuming that your 'Create Time' field is a "Time Field" not a
"Date/Time Field". I am talking data types here, not display values.

Just a guess... but I think your client is in a different timezone
than the ARS server?

The "Date/Time Field" values should be localized however the "Time
Field" will not be localized. (By design of those field types.)

-- 
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.


On 3/12/07, Opela, Gary L Contr OC-ALC/ITMA
<[EMAIL PROTECTED]> wrote:
> **
>
>
>
> Okay, so here is a weird one
>
>
>
> On one of our servers, on one application, we have a Create Date field
(this
> standard core field) and a create time field. The create time field is
set
> to $TIME$ by a filter on submit.
>
>
>
> The create time and create date fields are off from each other by an
hour.
> The Create Date field shows the correct time, 7:30, and the Create
Time
> field shows 6:30...
>
>
>
> Help


___
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 Test Results on March 11th 8:00 AM

[Opela, Gary L Contr OC-ALC/ITMA]

Further Clarification on this:

 

If I use $TIMESTAMP$ to set a Time field, then it is off by an hour,
however if I use $TIMESTAMP$ to set a Date/Time field, then it is fine.
The same is consistent with using $TIME$. If I use $TIME$ to set a
Date/Time field, it is correct, but if I use $TIME$ to set a Date/Time
field, then it is incorrect.

 

This is consistent across the mid-tier and the user tool. 

 

MS SQL 2k

Windows 2k

Remedy 6.3 no patch on server

Remedy 6.3 p21 on mid-tier

UT 6.3 no patch and patch 20

 

Thanks for any help.

 



From: Opela, Gary L Contr OC-ALC/ITMA 
Sent: Monday, March 12, 2007 7:58 AM
To: 'arslist@ARSLIST.ORG'
Subject: RE: DST Test Results on March 11th 8:00 AM

 

Okay, so here is a weird one

 

On one of our servers, on one application, we have a Create Date field
(this standard core field) and a create time field. The create time
field is set to $TIME$ by a filter on submit. 

 

The create time and create date fields are off from each other by an
hour. The Create Date field shows the correct time, 7:30, and the Create
Time field shows 6:30...

 

Help

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Nall, Roger
Sent: Monday, March 12, 2007 2:41 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

 

You are correct. However, I am the only one in my company using the AR
User Preference form. We are a Citrix shop and are not able to use the
AR User Preference form across the board until we upgrade to 7.01. It
has to do with the way the preference value is stored in the registry.
That being said, everyone else uses Citrix to launch Remedy which means
they each have a centralized ar.ini file. I am at a loss as to how to
proceed from here. Should we remove the TZ values from the ini files and
hope they don't reset them? Any ideas are most welcome.

 

Thanks,

 

Roger A. Nall

Manager, OSSNMS Remedy

T-Mobile USA

Desk: 813-348-2556(New)

Cell: 973-652-6723

FAX: 813-348-2565

sf49fanv AIM IM

RogerNall   Yahoo IM

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas Bean
Sent: Monday, March 12, 2007 1:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

 

Roger,

You might check to make sure you don't have the time zone set in the AR
User Preferences form.  That could cause the times to be displayed one
hour off.  As long as Windows is patched, the User tool should pull the
correct time zone settings from the OS.

 

--Thomas

 

- Original Message - 

From: Nall, Roger <mailto:[EMAIL PROTECTED]>  

Newsgroups: gmane.comp.crm.arsystem.general

To: arslist@ARSLIST.ORG 

Sent: Sunday, March 11, 2007 13:55

Subject: Re: DST Test Results on March 11th 8:00 AM

 

** 

I did nothing as well but all of my times are off by one hour.
According to BMC this should not have happened. I do not use the
mid-tier. I am on ARS 6.03, patch 16, windows2k, sql2k. All OS were
patched. Has anyone else seen this behavior?

Thanks,


Roger Nall
Manager, OSSNMS  Remedy
T-Mobile, USA
Desk: 813-348-2556(NEW)
Mobile:973-652-6723
FAX: 813-348-2565
Sf49fanv  AIMIM
RogerNall. Yahoo IM

Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Sanford, Claire
[mailto:[EMAIL PROTECTED]
Sent:   Sunday, March 11, 2007 10:29 AM Pacific Standard Time
To: arslist@ARSLIST.ORG
        Subject:Re: DST Test Results on March 11th 8:00 AM

Ok, so I did NOTHING.  I made no changes, added no patches (I am
sure
this will bite me some time down the road) and everything worked
as it
was supposed to work.



The time changed on the server, the time changed in Remedy, the
time was
correct on my tickets and the escalations worked as they should
have.



The end result...  I lose an hour of sleep in the morning, the
dogs gain
an hour of daylight for the park after work!



Claire





From: Action Request System discussion list(ARSList)
__20060125___This posting was submitted with
HTML in it___

__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 Test Results on March 11th 8:00 AM

[Carey Matthew Black]

Gary,


Assuming that your 'Create Time' field is a "Time Field" not a
"Date/Time Field". I am talking data types here, not display values.

Just a guess... but I think your client is in a different timezone
than the ARS server?

The "Date/Time Field" values should be localized however the "Time
Field" will not be localized. (By design of those field types.)

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.


On 3/12/07, Opela, Gary L Contr OC-ALC/ITMA
<[EMAIL PROTECTED]> wrote:

**



Okay, so here is a weird one….



On one of our servers, on one application, we have a Create Date field (this
standard core field) and a create time field. The create time field is set
to $TIME$ by a filter on submit.



The create time and create date fields are off from each other by an hour.
The Create Date field shows the correct time, 7:30, and the Create Time
field shows 6:30…



Help


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers 
Are"

Re: DST Test Results on March 11th 8:00 AM

[Randy Simon]

I had something very similar. The tickets created on Sunday 03/11 all had the 
Create Date of 03/10 except for the ones created prior to 2:00 AM.
The Create Date/Time was accurate.
The next day Monday, today they are both accurate and in sync. No changes done, 
it self corrected.

-Original Message-
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
Behalf Of Opela, Gary L Contr OC-ALC/ITMA
Sent: Monday, March 12, 2007 8:58 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM


** 

Okay, so here is a weird one

 

On one of our servers, on one application, we have a Create Date field (this 
standard core field) and a create time field. The create time field is set to 
$TIME$ by a filter on submit. 

 

The create time and create date fields are off from each other by an hour. The 
Create Date field shows the correct time, 7:30, and the Create Time field shows 
6:30...

 

Help

 


  _  


From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Nall, Roger
Sent: Monday, March 12, 2007 2:41 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

 

You are correct. However, I am the only one in my company using the AR User 
Preference form. We are a Citrix shop and are not able to use the AR User 
Preference form across the board until we upgrade to 7.01. It has to do with 
the way the preference value is stored in the registry. That being said, 
everyone else uses Citrix to launch Remedy which means they each have a 
centralized ar.ini file. I am at a loss as to how to proceed from here. Should 
we remove the TZ values from the ini files and hope they don't reset them? Any 
ideas are most welcome.

 

Thanks,

 

Roger A. Nall

Manager, OSSNMS Remedy

T-Mobile USA

Desk: 813-348-2556(New)

Cell: 973-652-6723

FAX: 813-348-2565

sf49fanv AIM IM

RogerNall   Yahoo IM

 


  _  


From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] 
On Behalf Of Thomas Bean
Sent: Monday, March 12, 2007 1:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

 

Roger,

You might check to make sure you don't have the time zone set in the AR User 
Preferences form.  That could cause the times to be displayed one hour off.  As 
long as Windows is patched, the User tool should pull the correct time zone 
settings from the OS.

 

--Thomas

 

- Original Message - 

From: Nall,  <mailto:[EMAIL PROTECTED]> Roger 

Newsgroups: gmane.comp.crm.arsystem.general

To: arslist@ARSLIST.ORG 

Sent: Sunday, March 11, 2007 13:55

Subject: Re: DST Test Results on March 11th 8:00 AM

 

** 

I did nothing as well but all of my times are off by one hour. According to BMC 
this should not have happened. I do not use the mid-tier. I am on ARS 6.03, 
patch 16, windows2k, sql2k. All OS were patched. Has anyone else seen this 
behavior?

Thanks,


Roger Nall
Manager, OSSNMS  Remedy
T-Mobile, USA
Desk: 813-348-2556(NEW)
Mobile:973-652-6723
FAX: 813-348-2565
Sf49fanv  AIMIM
RogerNall. Yahoo IM

Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Sanford, Claire [ mailto:[EMAIL PROTECTED]
Sent:   Sunday, March 11, 2007 10:29 AM Pacific Standard Time
To: arslist@ARSLIST.ORG
Subject:Re: DST Test Results on March 11th 8:00 AM

Ok, so I did NOTHING.  I made no changes, added no patches (I am sure
this will bite me some time down the road) and everything worked as it
was supposed to work.



The time changed on the server, the time changed in Remedy, the time was
correct on my tickets and the escalations worked as they should have.



The end result...  I lose an hour of sleep in the morning, the dogs gain
an hour of daylight for the park after work!



Claire





From: Action Request System discussion list(ARSList)
__20060125___This posting was submitted with HTML in it___

__20060125___This posting was submitted with HTML in it___ 
__20060125___This posting was submitted with HTML in it___ 
__20060125___This posting was submitted with HTML in it___




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 compu

Re: DST Test Results on March 11th 8:00 AM

[Heider, Stephen]

Another, or additional, method would be to run a Direct SQL command each
time users login (loads the main form)

UPDATE AR_System_User_Preference SET Time_Zone = NULL WHERE Submitter =
'$USER$'

This would take effect the next time the user logged in. I actually do
this with a stored procedure that sets a number of settings in the
preference form.  Users are allowed to change some settings in the User
Tool but there are some that I want every user to have.  This has
completely eliminated support calls for fixing User Tool settings.

You could also simply Null out the field for all users at once using a
tool such as SQL Query Analyzer.

UPDATE AR_System_User_Preference SET Time_Zone = NULL

HTH

Stephen

-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black
Sent: Monday, March 12, 2007 8:43 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

Roger,

We found that the User Tool must NOT have a TZ setting value for the
values to be correct for the 2007 DST range. That lack of a setting
however also makes the pre 2007 DST values display incorrectly too.
(So pick your poison.)


We added two active links (Only for the User Tool because our Mid-Tier
v6.3 patch 21 appears to be ok with or without a client TZ setting.) to
our major forms that use a combination of the following workflow...

AL #1:
zTemp = $PROCESS$ PERFORM-ACTION-GET-PREFERENCE 20123

AL #2:
if zTemp != NULL
--> Message "Your Time Zone setting was found to have a value. Please
review the following information..."
  Then we do a Run Process: PERFORM-ACTION-OPEN-URL new "http."
  To open a quick PDF that we put together to show the user how to clear
the setting.

We also tried to use the GET/SET preference commands, but they appeared
to not become effected for the User Tool until the user logged out and
back in. Sigh. But the user doing it via
Tools-->Options did become effective immediately. So we opted to let
the user set the setting.

HTH

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.


On 3/12/07, Nall, Roger <[EMAIL PROTECTED]> wrote:
> **
>
>
>
> You are correct. However, I am the only one in my company using the AR

> User Preference form. We are a Citrix shop and are not able to use the

> AR User Preference form across the board until we upgrade to 7.01. It 
> has to do with the way the preference value is stored in the registry.

> That being said, everyone else uses Citrix to launch Remedy which 
> means they each have a centralized ar.ini file. I am at a loss as to
how to proceed from here.
> Should we remove the TZ values from the ini files and hope they don't 
> reset them? Any ideas are most welcome.
>
>
>
> Thanks,
>
>
>
>
> Roger A. Nall
>
> Manager, OSSNMS Remedy
>
> T-Mobile USA
>
> Desk: 813-348-2556(New)
>
> Cell: 973-652-6723
>
> FAX: 813-348-2565
>
> sf49fanv AIM IM
>
> RogerNall   Yahoo IM


___
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 Test Results on March 11th 8:00 AM

[Opela, Gary L Contr OC-ALC/ITMA]

Okay, so here is a weird one

 

On one of our servers, on one application, we have a Create Date field
(this standard core field) and a create time field. The create time
field is set to $TIME$ by a filter on submit. 

 

The create time and create date fields are off from each other by an
hour. The Create Date field shows the correct time, 7:30, and the Create
Time field shows 6:30...

 

Help

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Nall, Roger
Sent: Monday, March 12, 2007 2:41 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

 

You are correct. However, I am the only one in my company using the AR
User Preference form. We are a Citrix shop and are not able to use the
AR User Preference form across the board until we upgrade to 7.01. It
has to do with the way the preference value is stored in the registry.
That being said, everyone else uses Citrix to launch Remedy which means
they each have a centralized ar.ini file. I am at a loss as to how to
proceed from here. Should we remove the TZ values from the ini files and
hope they don't reset them? Any ideas are most welcome.

 

Thanks,

 

Roger A. Nall

Manager, OSSNMS Remedy

T-Mobile USA

Desk: 813-348-2556(New)

Cell: 973-652-6723

FAX: 813-348-2565

sf49fanv AIM IM

RogerNall   Yahoo IM

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas Bean
Sent: Monday, March 12, 2007 1:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

 

Roger,

You might check to make sure you don't have the time zone set in the AR
User Preferences form.  That could cause the times to be displayed one
hour off.  As long as Windows is patched, the User tool should pull the
correct time zone settings from the OS.

 

--Thomas

 

- Original Message - 

From: Nall, Roger <mailto:[EMAIL PROTECTED]>  

Newsgroups: gmane.comp.crm.arsystem.general

To: arslist@ARSLIST.ORG 

Sent: Sunday, March 11, 2007 13:55

        Subject: Re: DST Test Results on March 11th 8:00 AM

 

** 

I did nothing as well but all of my times are off by one hour.
According to BMC this should not have happened. I do not use the
mid-tier. I am on ARS 6.03, patch 16, windows2k, sql2k. All OS were
patched. Has anyone else seen this behavior?

Thanks,


Roger Nall
Manager, OSSNMS  Remedy
T-Mobile, USA
Desk: 813-348-2556(NEW)
Mobile:973-652-6723
FAX: 813-348-2565
Sf49fanv  AIMIM
RogerNall. Yahoo IM

Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Sanford, Claire
[mailto:[EMAIL PROTECTED]
Sent:   Sunday, March 11, 2007 10:29 AM Pacific Standard Time
To: arslist@ARSLIST.ORG
Subject:Re: DST Test Results on March 11th 8:00 AM

Ok, so I did NOTHING.  I made no changes, added no patches (I am
sure
this will bite me some time down the road) and everything worked
as it
was supposed to work.



The time changed on the server, the time changed in Remedy, the
time was
correct on my tickets and the escalations worked as they should
have.



The end result...  I lose an hour of sleep in the morning, the
dogs gain
an hour of daylight for the park after work!



Claire





From: Action Request System discussion list(ARSList)
__20060125___This posting was submitted with
HTML in it___

__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 Test Results on March 11th 8:00 AM

[Carey Matthew Black]

Roger,

We found that the User Tool must NOT have a TZ setting value for the
values to be correct for the 2007 DST range. That lack of a setting
however also makes the pre 2007 DST values display incorrectly too.
(So pick your poison.)


We added two active links (Only for the User Tool because our Mid-Tier
v6.3 patch 21 appears to be ok with or without a client TZ setting.)
to our major forms that use a combination of the following workflow...

AL #1:
zTemp = $PROCESS$ PERFORM-ACTION-GET-PREFERENCE 20123

AL #2:
if zTemp != NULL
--> Message "Your Time Zone setting was found to have a value. Please
review the following information..."
 Then we do a Run Process: PERFORM-ACTION-OPEN-URL new "http."
 To open a quick PDF that we put together to show the user how to
clear the setting.

We also tried to use the GET/SET preference commands, but they
appeared to not become effected for the User Tool until the user
logged out and back in. Sigh. But the user doing it via
Tools-->Options did become effective immediately. So we opted to let
the user set the setting.

HTH

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.


On 3/12/07, Nall, Roger <[EMAIL PROTECTED]> wrote:

**



You are correct. However, I am the only one in my company using the AR User
Preference form. We are a Citrix shop and are not able to use the AR User
Preference form across the board until we upgrade to 7.01. It has to do with
the way the preference value is stored in the registry. That being said,
everyone else uses Citrix to launch Remedy which means they each have a
centralized ar.ini file. I am at a loss as to how to proceed from here.
Should we remove the TZ values from the ini files and hope they don't reset
them? Any ideas are most welcome.



Thanks,




Roger A. Nall

Manager, OSSNMS Remedy

T-Mobile USA

Desk: 813-348-2556(New)

Cell: 973-652-6723

FAX: 813-348-2565

sf49fanv AIM IM

RogerNall   Yahoo IM


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers 
Are"

Re: DST Test Results on March 11th 8:00 AM

[Nall, Roger]

You are correct. However, I am the only one in my company using the AR
User Preference form. We are a Citrix shop and are not able to use the
AR User Preference form across the board until we upgrade to 7.01. It
has to do with the way the preference value is stored in the registry.
That being said, everyone else uses Citrix to launch Remedy which means
they each have a centralized ar.ini file. I am at a loss as to how to
proceed from here. Should we remove the TZ values from the ini files and
hope they don't reset them? Any ideas are most welcome.

 

Thanks,

 

Roger A. Nall

Manager, OSSNMS Remedy

T-Mobile USA

Desk: 813-348-2556(New)

Cell: 973-652-6723

FAX: 813-348-2565

sf49fanv AIM IM

RogerNall   Yahoo IM

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas Bean
Sent: Monday, March 12, 2007 1:33 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

 

Roger,

You might check to make sure you don't have the time zone set in the AR
User Preferences form.  That could cause the times to be displayed one
hour off.  As long as Windows is patched, the User tool should pull the
correct time zone settings from the OS.

 

--Thomas

 

- Original Message - 

From: Nall, Roger <mailto:[EMAIL PROTECTED]>  

Newsgroups: gmane.comp.crm.arsystem.general

To: arslist@ARSLIST.ORG 

Sent: Sunday, March 11, 2007 13:55

        Subject: Re: DST Test Results on March 11th 8:00 AM

 

** 

I did nothing as well but all of my times are off by one hour.
According to BMC this should not have happened. I do not use the
mid-tier. I am on ARS 6.03, patch 16, windows2k, sql2k. All OS were
patched. Has anyone else seen this behavior?

Thanks,


Roger Nall
Manager, OSSNMS  Remedy
T-Mobile, USA
Desk: 813-348-2556(NEW)
Mobile:973-652-6723
FAX: 813-348-2565
Sf49fanv  AIMIM
RogerNall. Yahoo IM

Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Sanford, Claire
[mailto:[EMAIL PROTECTED]
Sent:   Sunday, March 11, 2007 10:29 AM Pacific Standard Time
To: arslist@ARSLIST.ORG
Subject:Re: DST Test Results on March 11th 8:00 AM

Ok, so I did NOTHING.  I made no changes, added no patches (I am
sure
this will bite me some time down the road) and everything worked
as it
was supposed to work.



The time changed on the server, the time changed in Remedy, the
time was
correct on my tickets and the escalations worked as they should
have.



The end result...  I lose an hour of sleep in the morning, the
dogs gain
an hour of daylight for the park after work!



Claire





From: Action Request System discussion list(ARSList)
__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 Test Results on March 11th 8:00 AM

[Thomas Bean]

Re: DST Test Results on March 11th 8:00 AMRoger,
You might check to make sure you don't have the time zone set in the AR User 
Preferences form.  That could cause the times to be displayed one hour off.  As 
long as Windows is patched, the User tool should pull the correct time zone 
settings from the OS.

--Thomas

  - Original Message - 
  From: Nall, Roger 
  Newsgroups: gmane.comp.crm.arsystem.general
  To: arslist@ARSLIST.ORG 
  Sent: Sunday, March 11, 2007 13:55
  Subject: Re: DST Test Results on March 11th 8:00 AM


  ** 
  I did nothing as well but all of my times are off by one hour. According to 
BMC this should not have happened. I do not use the mid-tier. I am on ARS 6.03, 
patch 16, windows2k, sql2k. All OS were patched. Has anyone else seen this 
behavior?

  Thanks,


  Roger Nall
  Manager, OSSNMS  Remedy
  T-Mobile, USA
  Desk: 813-348-2556(NEW)
  Mobile:973-652-6723
  FAX: 813-348-2565
  Sf49fanv  AIMIM
  RogerNall. Yahoo IM

  Sent from my GoodLink Wireless Handheld (www.good.com)

   -Original Message-
  From:   Sanford, Claire [mailto:[EMAIL PROTECTED]
  Sent:   Sunday, March 11, 2007 10:29 AM Pacific Standard Time
  To: arslist@ARSLIST.ORG
  Subject:        Re: DST Test Results on March 11th 8:00 AM

  Ok, so I did NOTHING.  I made no changes, added no patches (I am sure
  this will bite me some time down the road) and everything worked as it
  was supposed to work.



  The time changed on the server, the time changed in Remedy, the time was
  correct on my tickets and the escalations worked as they should have.



  The end result...  I lose an hour of sleep in the morning, the dogs gain
  an hour of daylight for the park after work!



  Claire



  

  From: Action Request System discussion list(ARSList)
  __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 Test Results on March 11th 8:00 AM

[Nall, Roger]

The server has the correct time but at the client level the time is off
by one hour. It was correct until I re-selected my time zone. Any ideas
would be helpful.

 

Thanks,

 

 

Roger A. Nall

Manager, OSSNMS Remedy

T-Mobile USA

Desk: 813-348-2556(New)

Cell: 973-652-6723

FAX: 813-348-2565

sf49fanv AIM IM

RogerNall   Yahoo IM

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Grooms, Frederick W
Sent: Sunday, March 11, 2007 3:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

 

You say your times are off by an hour?   Is this on the server or the
client?

 

 

I had noticed that for me the MS patch did not take effect until I went
in and re-selected the time zone.  It seems that MS keeps time zone info
in the registry in multiple places.  

The list of zones is in: 

   [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones]

The current zone info (that controls the change) is in:

 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
]

 

Fred

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Nall, Roger
Sent: Sunday, March 11, 2007 1:55 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM

** 

I did nothing as well but all of my times are off by one hour. According
to BMC this should not have happened. I do not use the mid-tier. I am on
ARS 6.03, patch 16, windows2k, sql2k. All OS were patched. Has anyone
else seen this behavior?

Thanks,


Roger Nall
Manager, OSSNMS  Remedy
T-Mobile, USA
Desk: 813-348-2556(NEW)
Mobile:973-652-6723
FAX: 813-348-2565
Sf49fanv  AIMIM
RogerNall. Yahoo IM

Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Sanford, Claire [mailto:[EMAIL PROTECTED]
Sent:   Sunday, March 11, 2007 10:29 AM Pacific Standard Time
To: arslist@ARSLIST.ORG
Subject:Re: DST Test Results on March 11th 8:00 AM

Ok, so I did NOTHING.  I made no changes, added no patches (I am sure
this will bite me some time down the road) and everything worked as it
was supposed to work.



The time changed on the server, the time changed in Remedy, the time was
correct on my tickets and the escalations worked as they should have.



The end result...  I lose an hour of sleep in the morning, the dogs gain
an hour of daylight for the park after work!



Claire





From: Action Request System discussion list(ARSList)
__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 Microsoft Hotfix

[Easter, David]

The instructions for the DLL's are:
a Install the two DLL's into the C:\Windows\System32 folder or the
System32 folder where Windows is installed. (Sometimes the Windows
operating system is installed into a folder other than C:\Windows.)

b Restart the machine.

The technical bulletin describes how to set the TZ variable either on
the client or the server.  If you're talking about the server, use use
the "SET" command.  To quote:
For the AR System server, set the TZ variable to the appropriate time
zone and start all AR System processes from within this shell. For
example, to set the TZ variable to the Pacific Time Zone, enter this
command:

SET TZ=PST8PDT

In other words, from wherever you start the AR System server, set the TZ
variable prior to starting.

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.
 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Warren Baltimore
Sent: Saturday, March 10, 2007 4:09 PM
To: arslist@ARSLIST.ORG
Subject: DST Microsoft Hotfix


** 
Well, I got the two .dll's from BMC, but with no indication of what to
do with them.  When I asked, I was told to contact Microsoft.
 
I'm not a systems person, I can patch things if given instructions on
how to do that.  But I can't find anything at MS or BMC that tells me
what to do.  From what I read, I THINK it needs to go in the same
directory as the ARSERVER.EXE file, but I'm not positive.  Also, I'm not
clear on how to set the tz variable (the document that david provided
discusses a shell).
 
I'm running ARS 7.0.1 patch 1 on a Windows 2000 sp4 server.
 
Anybody willing to tell me what to do?
 
Signed,
 
Sleepless in Seattle

-- 
Warren R. Baltimore II
Remedy Developer
UW Medicine IT Services
School of Medicine
University of Washington
Box 358220
1325 Fourth Ave, Suite 2000
Seattle, WA 98101

The opinions expressed in this e-mail are in no way those of the
University of Washington, or the State of Washington.  They are my own. 
__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 Test Results on March 11th 8:00 AM

[Grooms, Frederick W]

You say your times are off by an hour?   Is this on the server or the
client?
 
 
I had noticed that for me the MS patch did not take effect until I went
in and re-selected the time zone.  It seems that MS keeps time zone info
in the registry in multiple places.  
The list of zones is in: 
   [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones]
The current zone info (that controls the change) is in:
 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
]
 
Fred



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Nall, Roger
Sent: Sunday, March 11, 2007 1:55 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM


** 

I did nothing as well but all of my times are off by one hour. According
to BMC this should not have happened. I do not use the mid-tier. I am on
ARS 6.03, patch 16, windows2k, sql2k. All OS were patched. Has anyone
else seen this behavior?

Thanks,


Roger Nall
Manager, OSSNMS  Remedy
T-Mobile, USA
Desk: 813-348-2556(NEW)
Mobile:973-652-6723
FAX: 813-348-2565
Sf49fanv  AIMIM
RogerNall. Yahoo IM

Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Sanford, Claire [mailto:[EMAIL PROTECTED]
Sent:   Sunday, March 11, 2007 10:29 AM Pacific Standard Time
To: arslist@ARSLIST.ORG
Subject:Re: DST Test Results on March 11th 8:00 AM

Ok, so I did NOTHING.  I made no changes, added no patches (I am sure
this will bite me some time down the road) and everything worked as it
was supposed to work.



The time changed on the server, the time changed in Remedy, the time was
correct on my tickets and the escalations worked as they should have.



The end result...  I lose an hour of sleep in the morning, the dogs gain
an hour of daylight for the park after work!



Claire





From: Action Request System discussion list(ARSList)
__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 Test Results on March 11th 8:00 AM

[Lucero, Michelle - IST contractor]

Eli,
 
I'm glad to hear that it was successful.  Did you use the installer or
the file replacement method.  What version/patch were you on before?
 
Inquiring minds want to know.
 
And, you are definitely a risk taker. :)  We applied ours Friday
night/Saturday morning.
 
Michelle



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Eli Schilling
Sent: Sunday, March 11, 2007 1:43 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM


** 

I have to admit I was very sketchy about installing the DST patch.  I
did it in a test environment 3 times and each time it failed to produce
the desired results.  My windows server would jump forward an hour but
Remedy was still time-stamping records an hour behind.  There were no
other failures so nothing lost but nothing gained...

 

I bit the bullet and implemented the patch in production around 12:30am
this morning.  The clock struck 2:00am/3:00am, I created a new ticket
and voila...it worked!  All other tests were successful and there have
not yet been any issues reported to the help desk.

 

Perhaps its time to rebuild my test environment...

 

Happy early DST to all!

 

-Eli

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Palmer
Sent: Sunday, March 11, 2007 6:28 AM
To: arslist@ARSLIST.ORG
Subject: DST Test Results on March 11th 8:00 AM

 

** 

Well I hope everyone's testing went as well as mine.  I found NO adverse
results in my testing.  We have basic Remedy/HelpDesk application usage
and our main concern was business time calculations.  I also looked at
historical data and found no adverse results. 

 

I'm a happy camper!

 

Susan

ShopperTrak

 

 

Server:  ARS 5.1.2 Patch 1428

OS:  Windows NT 5.0  2CPU's 4G Memory
Database:  Oracle 9i2
User:  ARS 5.1.2 Patch 1316

User OS:  XP, NT, Win 2000

Admin:  ARS 5.1.2 Patch 1289
Crystal that created reports:  9
 

__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 Test Results on March 11th 8:00 AM

[Lucero, Michelle - IST contractor]

I envy you, Claire.  Doing nothing in my opinion would have been better
in this case.  Applying a patch to production that had only been
released 10 days before with only a few days to test in DEV is a risk
that I don't care to take again.
 
My trust level for the BMC Remedy patches is simply not there anymore.
If it were up to me, I think it will be a long time coming before we
apply any ARSERVER patches.
 
The Patch 21 file replacement method on a server that was less than P19
failed miserably with a server that wouldn't come up.  We had to back
out and run the installer.  Not something I wanted to do since as
mentioned in a post last month, up to 44 forms were updated.  This of
course included the stripping of permissions on the User and Group
forms.
 
I do apologize to everyone for sounding so negative, latelyI'm just
plain tired.
 
Patch Burnout,
Michelle
 
Mid-Tier 7.0.01 P1 (with FB special patch; went smooth)
ARS 6.3 P21 (P18-->P20-->P21)
Flashboards 6.3 P20
Email Engine 6.3 P21
Windows 2003/SQL Server 2000



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Sanford, Claire
Sent: Sunday, March 11, 2007 11:20 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Test Results on March 11th 8:00 AM


** 

Ok, so I did NOTHING.  I made no changes, added no patches (I am sure
this will bite me some time down the road) and everything worked as it
was supposed to work.

 

The time changed on the server, the time changed in Remedy, the time was
correct on my tickets and the escalations worked as they should have.

 

The end result...  I lose an hour of sleep in the morning, the dogs gain
an hour of daylight for the park after work!

 

Claire

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Palmer
Sent: Sunday, March 11, 2007 8:28 AM
To: arslist@ARSLIST.ORG
Subject: DST Test Results on March 11th 8:00 AM

 

** 

Well I hope everyone's testing went as well as mine.  I found NO adverse
results in my testing.  We have basic Remedy/HelpDesk application usage
and our main concern was business time calculations.  I also looked at
historical data and found no adverse results. 

 

I'm a happy camper!

 

Susan

ShopperTrak

 

 

Server:  ARS 5.1.2 Patch 1428

OS:  Windows NT 5.0  2CPU's 4G Memory
Database:  Oracle 9i2
User:  ARS 5.1.2 Patch 1316

User OS:  XP, NT, Win 2000

Admin:  ARS 5.1.2 Patch 1289
Crystal that created reports:  9
 

__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 Test Results on March 11th 8:00 AM

[Nall, Roger]

I did nothing as well but all of my times are off by one hour. According to BMC 
this should not have happened. I do not use the mid-tier. I am on ARS 6.03, 
patch 16, windows2k, sql2k. All OS were patched. Has anyone else seen this 
behavior?

Thanks,


Roger Nall
Manager, OSSNMS  Remedy 
T-Mobile, USA
Desk: 813-348-2556(NEW)
Mobile:973-652-6723
FAX: 813-348-2565
Sf49fanv  AIMIM
RogerNall. Yahoo IM

Sent from my GoodLink Wireless Handheld (www.good.com)

 -Original Message-
From:   Sanford, Claire [mailto:[EMAIL PROTECTED]
Sent:   Sunday, March 11, 2007 10:29 AM Pacific Standard Time
To: arslist@ARSLIST.ORG
Subject:Re: DST Test Results on March 11th 8:00 AM

Ok, so I did NOTHING.  I made no changes, added no patches (I am sure
this will bite me some time down the road) and everything worked as it
was supposed to work.

 

The time changed on the server, the time changed in Remedy, the time was
correct on my tickets and the escalations worked as they should have.

 

The end result...  I lose an hour of sleep in the morning, the dogs gain
an hour of daylight for the park after work!

 

Claire

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Palmer
Sent: Sunday, March 11, 2007 8:28 AM
To: arslist@ARSLIST.ORG
Subject: DST Test Results on March 11th 8:00 AM

 

** 

Well I hope everyone's testing went as well as mine.  I found NO adverse
results in my testing.  We have basic Remedy/HelpDesk application usage
and our main concern was business time calculations.  I also looked at
historical data and found no adverse results. 

 

I'm a happy camper!

 

Susan

ShopperTrak

 

 

Server:  ARS 5.1.2 Patch 1428

OS:  Windows NT 5.0  2CPU's 4G Memory
Database:  Oracle 9i2
User:  ARS 5.1.2 Patch 1316

User OS:  XP, NT, Win 2000

Admin:  ARS 5.1.2 Patch 1289
Crystal that created reports:  9
 

__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: DST Test Results on March 11th 8:00 AM

[Eli Schilling]

I have to admit I was very sketchy about installing the DST patch.  I
did it in a test environment 3 times and each time it failed to produce
the desired results.  My windows server would jump forward an hour but
Remedy was still time-stamping records an hour behind.  There were no
other failures so nothing lost but nothing gained...

 

I bit the bullet and implemented the patch in production around 12:30am
this morning.  The clock struck 2:00am/3:00am, I created a new ticket
and voila...it worked!  All other tests were successful and there have
not yet been any issues reported to the help desk.

 

Perhaps its time to rebuild my test environment...

 

Happy early DST to all!

 

-Eli

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Palmer
Sent: Sunday, March 11, 2007 6:28 AM
To: arslist@ARSLIST.ORG
Subject: DST Test Results on March 11th 8:00 AM

 

** 

Well I hope everyone's testing went as well as mine.  I found NO adverse
results in my testing.  We have basic Remedy/HelpDesk application usage
and our main concern was business time calculations.  I also looked at
historical data and found no adverse results. 

 

I'm a happy camper!

 

Susan

ShopperTrak

 

 

Server:  ARS 5.1.2 Patch 1428

OS:  Windows NT 5.0  2CPU's 4G Memory
Database:  Oracle 9i2
User:  ARS 5.1.2 Patch 1316

User OS:  XP, NT, Win 2000

Admin:  ARS 5.1.2 Patch 1289
Crystal that created reports:  9
 

__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 Test Results on March 11th 8:00 AM

[patrick zandi]

SAME SAME -- It was a NON-Event..
Solaris 9 / Oracle 9 (no dst patch) ARS 5.12 (no DST patch) ..
Solaris has the DST time change .. that was all that was needed for me..

Great .. Awesome.. Cool


On 3/11/07, Sanford, Claire <[EMAIL PROTECTED]> wrote:


**

Ok, so I did NOTHING.  I made no changes, added no patches (I am sure this
will bite me some time down the road) and everything worked as it was
supposed to work.



The time changed on the server, the time changed in Remedy, the time was
correct on my tickets and the escalations worked as they should have.



The end result…  I lose an hour of sleep in the morning, the dogs gain an
hour of daylight for the park after work!



Claire


 --

*From:* Action Request System discussion list(ARSList) [mailto:
[EMAIL PROTECTED] *On Behalf Of *Susan Palmer
*Sent:* Sunday, March 11, 2007 8:28 AM
*To:* arslist@ARSLIST.ORG
*Subject:* DST Test Results on March 11th 8:00 AM



**

Well I hope everyone's testing went as well as mine.  I found NO adverse
results in my testing.  We have basic Remedy/HelpDesk application usage and
our main concern was business time calculations.  I also looked at
historical data and found no adverse results.



I'm a happy camper!



Susan

ShopperTrak





Server:  ARS 5.1.2 Patch 1428

OS:  Windows NT 5.0  2CPU's 4G Memory
Database:  Oracle 9i2
User:  ARS 5.1.2 Patch 1316

User OS:  XP, NT, Win 2000

Admin:  ARS 5.1.2 Patch 1289
Crystal that created reports:  9


__20060125___This posting was submitted with HTML in
it___
__20060125___This posting was submitted with HTML in
it___





--
Patrick Zandi

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers 
Are"

Re: DST Microsoft Hotfix

[Warren Baltimore]

Thanks!  I'm pretty sure that it has to go in the same directory as the
executable.  I did do a search for the existing .dll's and found a number
everywhere but in the directory that I thought they should be...go figure.
After talking it over with my Director, I decided it would be best for me
not to touch a darn thing till I can get some concrete information from
Microsoft

In the mean time

I'm going to try and test the install that I have and see if I can replicate
the situation the hotfix is supposed to resolve.  If I can't, then I'm not
going to worry too much about it.

I'll let you all know.

Warren


On 3/10/07, Carey Matthew Black <[EMAIL PROTECTED]> wrote:


Warren,

I got the exact same answer from BMC. So at least they are consistent
in their level of quality. :)


My _guess_ is that you need to find any instances of those DLL's on
your host. I would suggest that you copy each and every individual
copy to an alternate location (that is not in the PATH setting for the
host) for safe keeping.

Then copy the new DLL over the old DLL's. (and replace each and every
copy of the file[s])

If one of those places that you already find those dll's is the server
install directory, then absolutely put them there too. :)  (Maybe even
put them there if they are not there I doubt it would cause any
issues.)

Then I would reboot the box and let the server/client restart as normal.


However... if for some reason windows will not let you overwrite the
existing files... then.

I would put the files in a new directory and add this directory to the
Path AT THE BEGINNING of the PATH string.

Then I would reboot the box and let the server/client restart as normal.

Again... that is just a guess

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.


On 3/10/07, Warren Baltimore <[EMAIL PROTECTED]> wrote:
> **
> Well, I got the two .dll's from BMC, but with no indication of what to
do
> with them.  When I asked, I was told to contact Microsoft.
>
> I'm not a systems person, I can patch things if given instructions on
how to
> do that.  But I can't find anything at MS or BMC that tells me what to
do.
> From what I read, I THINK it needs to go in the same directory as the
> ARSERVER.EXE file, but I'm not positive.  Also, I'm not clear on how to
set
> the tz variable (the document that david provided discusses a shell).
>
> I'm running ARS 7.0.1 patch 1 on a Windows 2000 sp4 server.
>
> Anybody willing to tell me what to do?
>
> Signed,
>
> Sleepless in Seattle
>
> --
> Warren R. Baltimore II
> Remedy Developer
> UW Medicine IT Services
> School of Medicine
> University of Washington
> Box 358220
> 1325 Fourth Ave, Suite 2000
>  Seattle, WA 98101


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"





--
Warren R. Baltimore II
Remedy Developer
UW Medicine IT Services
School of Medicine
University of Washington
Box 358220
1325 Fourth Ave, Suite 2000
Seattle, WA 98101

The opinions expressed in this e-mail are in no way those of the University
of Washington, or the State of Washington.  They are my own.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers 
Are"

Re: DST Test Results on March 11th 8:00 AM

[Sanford, Claire]

Ok, so I did NOTHING.  I made no changes, added no patches (I am sure
this will bite me some time down the road) and everything worked as it
was supposed to work.

 

The time changed on the server, the time changed in Remedy, the time was
correct on my tickets and the escalations worked as they should have.

 

The end result...  I lose an hour of sleep in the morning, the dogs gain
an hour of daylight for the park after work!

 

Claire

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Palmer
Sent: Sunday, March 11, 2007 8:28 AM
To: arslist@ARSLIST.ORG
Subject: DST Test Results on March 11th 8:00 AM

 

** 

Well I hope everyone's testing went as well as mine.  I found NO adverse
results in my testing.  We have basic Remedy/HelpDesk application usage
and our main concern was business time calculations.  I also looked at
historical data and found no adverse results. 

 

I'm a happy camper!

 

Susan

ShopperTrak

 

 

Server:  ARS 5.1.2 Patch 1428

OS:  Windows NT 5.0  2CPU's 4G Memory
Database:  Oracle 9i2
User:  ARS 5.1.2 Patch 1316

User OS:  XP, NT, Win 2000

Admin:  ARS 5.1.2 Patch 1289
Crystal that created reports:  9
 

__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 Test Results on March 11th 8:00 AM

[Axton]

Things are good here as well.  The only thing I I was concerned with
were 24hr business time calcs,  but no urgent tickets came in during
that window, so we were ok.  Dates are rendered the same before and
after the time change.  The only known issue is the MS client non-year
specific time changes.

Solaris 9
ARS 7.0.01 p001 unicode
DB: Oracle 9i unicode

Axton Grams

On 3/11/07, Susan Palmer <[EMAIL PROTECTED]> wrote:

**
Well I hope everyone's testing went as well as mine.  I found NO adverse
results in my testing.  We have basic Remedy/HelpDesk application usage and
our main concern was business time calculations.  I also looked at
historical data and found no adverse results.

I'm a happy camper!

Susan
ShopperTrak



Server:  ARS 5.1.2 Patch 1428
OS:  Windows NT 5.0  2CPU's 4G Memory
Database:  Oracle 9i2
User:  ARS 5.1.2 Patch 1316
User OS:  XP, NT, Win 2000
Admin:  ARS 5.1.2 Patch 1289
Crystal that created reports:  9
  __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 Microsoft Hotfix

[Axton]

Exchange hotfixes (circa 2000) used to require replacing dll's that
had active handles (would yield an error if user tried to overwrite or
delete); the way Microsoft worked around this was to renamed the
existing file (old version), then copy the patched file into place in
that directory.  Any active processes retain the handle on the
original file, and when the server is rebooted, the executables will
link against the new files.

Axton Grams

On 3/10/07, Carey Matthew Black <[EMAIL PROTECTED]> wrote:

Warren,

I got the exact same answer from BMC. So at least they are consistent
in their level of quality. :)


My _guess_ is that you need to find any instances of those DLL's on
your host. I would suggest that you copy each and every individual
copy to an alternate location (that is not in the PATH setting for the
host) for safe keeping.

Then copy the new DLL over the old DLL's. (and replace each and every
copy of the file[s])

If one of those places that you already find those dll's is the server
install directory, then absolutely put them there too. :)  (Maybe even
put them there if they are not there I doubt it would cause any
issues.)

Then I would reboot the box and let the server/client restart as normal.


However... if for some reason windows will not let you overwrite the
existing files... then.

I would put the files in a new directory and add this directory to the
Path AT THE BEGINNING of the PATH string.

Then I would reboot the box and let the server/client restart as normal.

Again... that is just a guess

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.


On 3/10/07, Warren Baltimore <[EMAIL PROTECTED]> wrote:
> **
> Well, I got the two .dll's from BMC, but with no indication of what to do
> with them.  When I asked, I was told to contact Microsoft.
>
> I'm not a systems person, I can patch things if given instructions on how to
> do that.  But I can't find anything at MS or BMC that tells me what to do.
> From what I read, I THINK it needs to go in the same directory as the
> ARSERVER.EXE file, but I'm not positive.  Also, I'm not clear on how to set
> the tz variable (the document that david provided discusses a shell).
>
> I'm running ARS 7.0.1 patch 1 on a Windows 2000 sp4 server.
>
> Anybody willing to tell me what to do?
>
> Signed,
>
> Sleepless in Seattle
>
> --
> Warren R. Baltimore II
> Remedy Developer
> UW Medicine IT Services
> School of Medicine
> University of Washington
> Box 358220
> 1325 Fourth Ave, Suite 2000
>  Seattle, WA 98101

___
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 Microsoft Hotfix

[Carey Matthew Black]

Warren,

I got the exact same answer from BMC. So at least they are consistent
in their level of quality. :)


My _guess_ is that you need to find any instances of those DLL's on
your host. I would suggest that you copy each and every individual
copy to an alternate location (that is not in the PATH setting for the
host) for safe keeping.

Then copy the new DLL over the old DLL's. (and replace each and every
copy of the file[s])

If one of those places that you already find those dll's is the server
install directory, then absolutely put them there too. :)  (Maybe even
put them there if they are not there I doubt it would cause any
issues.)

Then I would reboot the box and let the server/client restart as normal.


However... if for some reason windows will not let you overwrite the
existing files... then.

I would put the files in a new directory and add this directory to the
Path AT THE BEGINNING of the PATH string.

Then I would reboot the box and let the server/client restart as normal.

Again... that is just a guess

--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)

Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap Pick two.


On 3/10/07, Warren Baltimore <[EMAIL PROTECTED]> wrote:

**
Well, I got the two .dll's from BMC, but with no indication of what to do
with them.  When I asked, I was told to contact Microsoft.

I'm not a systems person, I can patch things if given instructions on how to
do that.  But I can't find anything at MS or BMC that tells me what to do.
From what I read, I THINK it needs to go in the same directory as the
ARSERVER.EXE file, but I'm not positive.  Also, I'm not clear on how to set
the tz variable (the document that david provided discusses a shell).

I'm running ARS 7.0.1 patch 1 on a Windows 2000 sp4 server.

Anybody willing to tell me what to do?

Signed,

Sleepless in Seattle

--
Warren R. Baltimore II
Remedy Developer
UW Medicine IT Services
School of Medicine
University of Washington
Box 358220
1325 Fourth Ave, Suite 2000
 Seattle, WA 98101


___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers 
Are"

Re: DST - UK and GMT Time

[Lucero, Michelle - IST contractor]

We found something interesting. Non-Issue, just interesting.

We have a little test form, unrelated to DST, but has a time converter
on it.  It converts a timestamp from regular time to EPOCH and vice
versa.

I know there is technically no such thing as March 11, 2007 02:00:00,
but the conversion for any time on that day between 2:00:00 AM and
2:59:59 AM yields a "3".  As in 3 seconds.  When converted back, it
takes us back to 12/31/1969 06:00:03 PM.  That conversion makes sense
from 3 seconds-->12/31/1969:06:00:03 PM.

But, I would think that 2:00:00 AM to 2:59:59. AM on a DST Sunday
might yield an error.

Any Daylight Savings Time Sunday for all years going forward yield the
same results.

This doesn't affect past dates.

This is a non-issue for us, but just thought it was kind of interesting.

Strange huh?

Enjoy your day.
Michelle
-Original Message-
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Axton
Sent: Wednesday, March 07, 2007 2:08 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST - UK and GMT Time

Compare the db values of the two timestamps and see if they are close.
 If they are off by an hour or more then you have a problem.  Remember
that all the dates in the db are stored in GMT, regardless of the
source of the data.

Axton Grams

On 3/7/07, Frank Caruso <[EMAIL PROTECTED]> wrote:
> ** Scenario:
>
> ARS Server is EST runnning 6.3 P20 on Solaris (DST patched) /Sybase
> MidTier is running 6.3 Patch20 on LINUX, TomCat and Apache
> Not using user preference records
> Bumped the ARS and Web servers ahead to 3/20/2007 A user in the US on
EST
> creates a record and the midtier displays the correct created date and
time.
>
> A user in the UK on GMT creates a record in the same table at the same
time
> but the create date and time is in EST.
>
> Any thoughts?
>
>
> __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: DST - UK and GMT Time

[Axton]

Compare the db values of the two timestamps and see if they are close.
If they are off by an hour or more then you have a problem.  Remember
that all the dates in the db are stored in GMT, regardless of the
source of the data.

Axton Grams

On 3/7/07, Frank Caruso <[EMAIL PROTECTED]> wrote:

** Scenario:

ARS Server is EST runnning 6.3 P20 on Solaris (DST patched) /Sybase
MidTier is running 6.3 Patch20 on LINUX, TomCat and Apache
Not using user preference records
Bumped the ARS and Web servers ahead to 3/20/2007 A user in the US on EST
creates a record and the midtier displays the correct created date and time.

A user in the UK on GMT creates a record in the same table at the same time
but the create date and time is in EST.

Any thoughts?


__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 - UK and GMT Time

[Lammey, Peter A.]

I think if the user in the UK has a record in AR System User Preference
and has specified on the Preference Server to use GMT for Time Zone in
their Tools/Options, the record from the Mid Tier would then display the
date and times in GMT.


Thanks 
Peter Lammey 
ESPN MIT Technical Services & Applications Management 
860-766-4761 

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Frank Caruso
Sent: Wednesday, March 07, 2007 12:41 PM
To: arslist@ARSLIST.ORG
Subject: DST - UK and GMT Time


** Scenario:


*   ARS Server is EST runnning 6.3 P20 on Solaris (DST patched)
/Sybase 
*   MidTier is running 6.3 Patch20 on LINUX, TomCat and Apache 
*   Not using user preference records 
*   Bumped the ARS and Web servers ahead to 3/20/2007 

A user in the US on EST creates a record and the midtier displays the
correct created date and time.

A user in the UK on GMT creates a record in the same table at the same
time but the create date and time is in EST. 

Any thoughts?


__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 Simulated Test - Failed

[Lammey, Peter A.]

In my test I actually had 2 dates that were being used.
One was the System Create Date (field 3) and another was a "Created"
Date (for lack of a better label) which was a date/time field set to
TIMESTAMP at the point that I was in submit mode for my ticket.
 
My client OS clock was set to 3/12/2007 1:18 PM which was the same set
on the AR server.
When I saved the ticket the "Created" Date was one hour off from the
Create Date (field 3).
 
Despite this, I came to find out that the OS on our AR Server was not in
fact patched for DST.



Thanks 
Peter Lammey 
ESPN MIT Technical Services & Applications Management 
860-766-4761 

 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Aaron Keller
Sent: Tuesday, March 06, 2007 3:35 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST Simulated Test - Failed


** 

But he didn't say the time was *displayed* incorrectly, he said it was
*saved* incorrectly.

Since the value for create time is set on the server, it should be set
to the server time, regardless of the client's time, or accuracy

 

I'd be interested to know how, in the test mentioned below, Peter
determined what time was saved.

 

-Aaron

* Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Easter, David
Sent: Friday, March 02, 2007 2:58 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST Simulated Test - Failed

 

Correct.  Time zone conversions are done at the client for data being
displayed or submitted by the client.

 

-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 Thomas Bean
Sent: Friday, March 02, 2007 11:41 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Simulated Test - Failed

** 

Yes, I believe it would matter -- timestamps are displayed according to
the client's offset from GMT, regardless whether the value was set by
server.

 

--Thomas

 

- Original Message - 

From: Aaron Keller <mailto:[EMAIL PROTECTED]>  

Newsgroups: gmane.comp.crm.arsystem.general

To: arslist@ARSLIST.ORG 

    Sent: Friday, March 02, 2007 13:20

Subject: Re: DST Simulated Test - Failed

 

** 

Would that matter?  Isn't create_date supposed to be set by the
server?

 

-Aaron

* Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 





From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Easter, David
Sent: Friday, March 02, 2007 2:04 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST Simulated Test - Failed

 

Did you patch the OS on the client doing the submission?  

 

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.

 





From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Lammey, Peter A.
Sent: Friday, March 02, 2007 10:24 AM
To: arslist@ARSLIST.ORG
Subject: DST Simulated Test - Failed

** 

We finished patching our Remedy ARS 6.3 dev server up to Patch
20 and also our server team patched our Application dev server's OS for
DST.

We adjusted the time on our dev server to March 12 and left the
time the same and I moved my machine's date up to March 12 (left the
time the same).

I created a test ticket and the ticket's create date was wrong: 

Time on the server was 3/12/2007 1:11:18 PM 
Create time saved on the ticket was set to 3/12/2007 2:11:18 PM.


It seems to us that the patch did not work. 

Has anyone else been able to simulate this kind of test to
verify Patch 20 and verify if it corrects the DST issue? 

 

Thanks 
Peter Lammey 
ESPN MIT Technical Services & Applications Management 
860-766-4761 

Re: DST Issues

[Axton]

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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 
On Behalf Of Axton
Sent: Tuesday, March 06, 2007 4:56 PM
To: arslist@ARSLIST.ORG
Subject: DST Issues

Reposting this because I've seen no replies and wasn't sure if it went into a 
black hole today when no posts were being sent.  I really need a sanity check 
on this to make sure I'm not out of whack.

Axton

I am seeing some strange results in my DST testing in regards to business time.

Environment:
ARServer 7.0.01 patch 001
SunOS 5.9 Generic_118558-26
Mid-Tier 7.0.01 patch 001
IBM WebSphere Application Server/6.0
IBM Java 1.4.2_11

I took 2 dates, a start and end date, performed a business time diff, then 
added the diff to the start date and subtracted it from the end date; all BT 
calculations are done in filters on the server side.
These are some of the results of the tests:

Here are the scenarios I ran using the Mid-Tier as my client, just to avoid 
potential client/MS DST issues:

* Test 0
Business Time Type: Business Time 1
TestID: 109
Start: 3/10/2007 1:00:00 PM
End: 3/10/2007 2:00:00 PM
Diff Seconds: 3600
Diff Minutes: 60
Diff Hours: 1
Workday: 24 Hr Tag
Holiday: 24 Hr Tag
Result of Add to Start: 3/10/2007 2:00:00 PM (for all 3 units) Result of 
Subtract from End: 3/10/2007 1:00:00 PM (for all 3 units)
* DB Values:
REQUEST_ID: 109
STARTDATE: 1173549600
ENDDATE: 1173553200
ENDDATE-STARTDATE: 3600

This one looks good.

* Test 1
TestID: 111
Business Time Type: Business Time 1
Start: 3/11/2007 1:00:00 AM
End: 3/11/2007 3:00:00 AM
Diff Seconds: 7200
Diff Minutes: 120
Diff Hours: 2
Workday: 24 Hr Tag
Holiday: 24 Hr Tag
Result of Add to Start: 3/11/2007 3:00:00 AM (for all 3 units) Result of 
Subtract from End: 3/11/2007 1:00:00 AM (for all 3 units)
* DB Values:
REQUEST_ID: 111
STARTDATE: 1173592800
ENDDATE: 1173596400
ENDDATE-STARTDATE: 3600

Something is off here; db difference returns 3600 seconds, BT diff returns 7200 
seconds.  At least the client/server translation appears to be working 
correctly.

* Test 2
TestID:

Re: DST Issues

[Easter, David]

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:[EMAIL PROTECTED] 
On Behalf Of Axton
Sent: Tuesday, March 06, 2007 4:56 PM
To: arslist@ARSLIST.ORG
Subject: DST Issues

Reposting this because I've seen no replies and wasn't sure if it went into a 
black hole today when no posts were being sent.  I really need a sanity check 
on this to make sure I'm not out of whack.

Axton

I am seeing some strange results in my DST testing in regards to business time.

Environment:
ARServer 7.0.01 patch 001
SunOS 5.9 Generic_118558-26
Mid-Tier 7.0.01 patch 001
IBM WebSphere Application Server/6.0
IBM Java 1.4.2_11

I took 2 dates, a start and end date, performed a business time diff, then 
added the diff to the start date and subtracted it from the end date; all BT 
calculations are done in filters on the server side.
These are some of the results of the tests:

Here are the scenarios I ran using the Mid-Tier as my client, just to avoid 
potential client/MS DST issues:

* Test 0
Business Time Type: Business Time 1
TestID: 109
Start: 3/10/2007 1:00:00 PM
End: 3/10/2007 2:00:00 PM
Diff Seconds: 3600
Diff Minutes: 60
Diff Hours: 1
Workday: 24 Hr Tag
Holiday: 24 Hr Tag
Result of Add to Start: 3/10/2007 2:00:00 PM (for all 3 units) Result of 
Subtract from End: 3/10/2007 1:00:00 PM (for all 3 units)
* DB Values:
REQUEST_ID: 109
STARTDATE: 1173549600
ENDDATE: 1173553200
ENDDATE-STARTDATE: 3600

This one looks good.

* Test 1
TestID: 111
Business Time Type: Business Time 1
Start: 3/11/2007 1:00:00 AM
End: 3/11/2007 3:00:00 AM
Diff Seconds: 7200
Diff Minutes: 120
Diff Hours: 2
Workday: 24 Hr Tag
Holiday: 24 Hr Tag
Result of Add to Start: 3/11/2007 3:00:00 AM (for all 3 units) Result of 
Subtract from End: 3/11/2007 1:00:00 AM (for all 3 units)
* DB Values:
REQUEST_ID: 111
STARTDATE: 1173592800
ENDDATE: 1173596400
ENDDATE-STARTDATE: 3600

Something is off here; db difference returns 3600 seconds, BT diff returns 7200 
seconds.  At least the client/server translation appears to be working 
correctly.

* Test 2
TestID: 115
Business Time Type: Business Time 1
Start: 3/11/2007 1:00:00 AM
End: 3/11/2007 2:00:00 AM
Diff Seconds: 3600
Diff Minutes: 60
Diff Hours: 1
Workday: 24 Hr Tag
Holiday: 24 Hr Tag
Result of Add to Start: 3/11/2007 2:00:00 AM (for all 3 units) Result of 
Subtract from End: 3/11/2007 1:00:00 AM (for all 3 units)
* DB Values:
REQUEST_ID: 115
STARTDATE: 116478
ENDDATE: 1164783600
ENDDATE-STARTDATE: 3600

This one looks good.

While the add and subtract put the date back at the expected values, the diffs 
seem to be off for test 1 (which covers the DST change).

For Test 1, I would expect to see 1 hour as the result of the business time 
diff (1:00-1:59, then jump to 3:00).

This is very odd.  Can someone give me a sanity check on what I think I should 
be seeing?  The same workflow was used to generate all the test results 
(filters on 1 form where I provide the BT version, holiday/workday/segments, 
start date, and end date).  The calculations are done properly when using the 
time difference provided by the diff, but I am concerned thi

Re: DST Simulated Test - Failed

[Aaron Keller]

But he didn't say the time was *displayed* incorrectly, he said it was
*saved* incorrectly.

Since the value for create time is set on the server, it should be set
to the server time, regardless of the client's time, or accuracy

 

I'd be interested to know how, in the test mentioned below, Peter
determined what time was saved.

 

-Aaron

* Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 



From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Easter, David
Sent: Friday, March 02, 2007 2:58 PM
To: arslist@ARSLIST.ORG
Subject: Re: DST Simulated Test - Failed

 

Correct.  Time zone conversions are done at the client for data being
displayed or submitted by the client.

 

-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 Thomas Bean
Sent: Friday, March 02, 2007 11:41 AM
To: arslist@ARSLIST.ORG
Subject: Re: DST Simulated Test - Failed

** 

Yes, I believe it would matter -- timestamps are displayed according to
the client's offset from GMT, regardless whether the value was set by
server.

 

--Thomas

 

- Original Message - 

From: Aaron Keller <mailto:[EMAIL PROTECTED]>  

Newsgroups: gmane.comp.crm.arsystem.general

To: arslist@ARSLIST.ORG 

Sent: Friday, March 02, 2007 13:20

Subject: Re: DST Simulated Test - Failed

 

** 

Would that matter?  Isn't create_date supposed to be set by the
server?

 

-Aaron

* Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 





From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Easter, David
Sent: Friday, March 02, 2007 2:04 PM
    To: arslist@ARSLIST.ORG
Subject: Re: DST Simulated Test - Failed

 

Did you patch the OS on the client doing the submission?  

 

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.

 





From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Lammey, Peter A.
Sent: Friday, March 02, 2007 10:24 AM
To: arslist@ARSLIST.ORG
Subject: DST Simulated Test - Failed

** 

We finished patching our Remedy ARS 6.3 dev server up to Patch
20 and also our server team patched our Application dev server's OS for
DST.

We adjusted the time on our dev server to March 12 and left the
time the same and I moved my machine's date up to March 12 (left the
time the same).

I created a test ticket and the ticket's create date was wrong: 

Time on the server was 3/12/2007 1:11:18 PM 
Create time saved on the ticket was set to 3/12/2007 2:11:18 PM.


It seems to us that the patch did not work. 

Has anyone else been able to simulate this kind of test to
verify Patch 20 and verify if it corrects the DST issue? 

 

Thanks 
Peter Lammey 
ESPN MIT Technical Services & Applications Management 
860-766-4761 

__20060125___This posting was submitted with
HTML in it___ 

SunCom is the wireless company that's committed to doing things
differently. 
 
Things we want you to know.
 
This e-mail and any files transmitted with it are confidential
and are intended solely for the use of the individual or entity to whom
they are addressed. This communication may contain material protected by
the attorney-client privilege. If you are not the intended recipient or
the person responsible for delivering the e-mail to the intended
recipient, be advised that you have received this e-mail in error and
that any use, dissemination, forwarding, printing or copying of this
e-mail is strictly prohibited.

__20060125___This posting was submitted with
HTML in it___ __20060125___This posting was
submitted wi

Re: DST Testing

[Axton]

Here is another interesting one.  To reiterate, these tests were
performed by taking two times, calculating the difference between the
two times using Application-Business-Time-Diff; then adding that diff
to the start time and subtracting that diff from the end time.

* Test 3
Business Time Type: Business Time 1
TestID: 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 Daus: 1
Workday: 24 Hr Tag
Holiday: 24 Hr Tag
Result of Add to Start (Seconds): 3/11/2007 11:00:00 PM
Result of Add to Start (Minutes): 3/11/2007 11:00:00 PM
Result of Add to Start (Hours): 3/11/2007 11:00:00 PM
Result of Add to Start (Days): 3/11/2007 11:00:00 PM
Result of Subtract from End (Seconds): 3/10/2007 11:00:00 PM
Result of Subtract from End (Minutes): 3/10/2007 11:00:00 PM
Result of Subtract from End (Hours): 3/10/2007 11:00:00 PM
Result of Subtract from End (Days): 3/11/2007 12:00:00 AM
* DB Values:
REQUEST_ID: 202
STARTDATE: 1173585600
ENDDATE: 1173668400
ENDDATE-STARTDATE: 82800

It appears in this case, that the business time subtract, when using
the unit of days, properly accounts for the DST changes (the result
has a 1 hr offset from the original time), when all other units do
not; at the same time, the business time add of 1 day does not work
consistently with subtract with a unit of "days", or I would have seen
3/12/2007 12:00:00 AM as the return value.

Notice that the db value for the time difference (end-start) does not
match that of the business time calculation
(Application-Business-Time-Diff).

This is just getting better and better, or should I say the rabbit
hole is getting deeper and deeper.

Axton Grams

On 3/6/07, Axton <[EMAIL PROTECTED]> wrote:

I meant to include this in the original post, but if you look at Test
1, it appears the values are written to the db properly in GMT time,
and if I subtract those times (epoch/integers) in the db I get back
3600 (what I expected), but business time 1 gives me a difference of
7200 seconds (2 hours) for the same start/end times.

Axton Grams

On 3/6/07, Axton <[EMAIL PROTECTED]> wrote:
> I am seeing some strange results in my DST testing in regards to business 
time.
>
> Environment:
> ARServer 7.0.01 patch 001
> SunOS 5.9 Generic_118558-26
> Mid-Tier 7.0.01 patch 001
> IBM WebSphere Application Server/6.0
> IBM Java 1.4.2_11
>
> I took 2 dates, a start and end date, performed a diff, then added the
> diff to the start and subtracted it from the end; all BT calculations
> are done in filters on the server side.  These are the results of 3 of
> those tests:
>
> Here are the scenarios I ran using the Mid-Tier (just to avoid
> potential client/MS DST issues):
>
> * Test 0
> Business Time Type: Business Time 1
> TestID: 109
> Start: 3/10/2007 1:00:00 PM
> End: 3/10/2007 2:00:00 PM
> Diff Seconds: 3600
> Diff Minutes: 60
> Diff Hours: 1
> Workday: 24 Hr Tag
> Holiday: 24 Hr Tag
> Result of Add to Start: 3/10/2007 2:00:00 PM (for all 3 units)
> Result of Subtract from End: 3/10/2007 1:00:00 PM (for all 3 units)
> * DB Values:
> REQUEST_ID: 109
> STARTDATE: 1173549600
> ENDDATE: 1173553200
> ENDDATE-STARTDATE: 3600
>
> * Test 1
> TestID: 111
> Business Time Type: Business Time 1
> Start: 3/11/2007 1:00:00 AM
> End: 3/11/2007 3:00:00 AM
> Diff Seconds: 7200
> Diff Minutes: 120
> Diff Hours: 2
> Workday: 24 Hr Tag
> Holiday: 24 Hr Tag
> Result of Add to Start: 3/11/2007 3:00:00 AM (for all 3 units)
> Result of Subtract from End: 3/11/2007 1:00:00 AM (for all 3 units)
> * DB Values:
> REQUEST_ID: 111
> STARTDATE: 1173592800
> ENDDATE: 1173596400
> ENDDATE-STARTDATE: 3600
>
> * Test 2
> TestID: 115
> Business Time Type: Business Time 1
> Start: 3/11/2007 1:00:00 AM
> End: 3/11/2007 2:00:00 AM
> Diff Seconds: 3600
> Diff Minutes: 60
> Diff Hours: 1
> Workday: 24 Hr Tag
> Holiday: 24 Hr Tag
> Result of Add to Start: 3/11/2007 2:00:00 AM (for all 3 units)
> Result of Subtract from End: 3/11/2007 1:00:00 AM (for all 3 units)
> * DB Values:
> REQUEST_ID: 115
> STARTDATE: 116478
> ENDDATE: 1164783600
> ENDDATE-STARTDATE: 3600
>
> While the add and subtract put the date back at the expected values,
> the diffs seem to be off for test 1 (which covers the DST switch).
>
> For Test 1, I would expect to see 1 hour as the result of the diff
> (1:00-1:59, then jump to 3:00).
>
> This is very odd.  Can someone give me a sanity check on what I think
> I should be seeing?  The same workflow was used to generate all the
> test results (filters on 1 form where I provide the BT version,
> holiday/workday/segments, start date, and end date).  The calculations
> are done properly when using the time difference provided by the diff,
> but I am concerned this will cause issues for time calculations where
> the offset is provided as a constant (e.g. 3/11/2007 1:00:00 AM + 4
> hours will result in 4/2/2006 5:00:00 AM, when it should result

Re: DST Testing

[Axton]

I meant to include this in the original post, but if you look at Test
1, it appears the values are written to the db properly in GMT time,
and if I subtract those times (epoch/integers) in the db I get back
3600 (what I expected), but business time 1 gives me a difference of
7200 seconds (2 hours) for the same start/end times.

Axton Grams

On 3/6/07, Axton <[EMAIL PROTECTED]> wrote:

I am seeing some strange results in my DST testing in regards to business time.

Environment:
ARServer 7.0.01 patch 001
SunOS 5.9 Generic_118558-26
Mid-Tier 7.0.01 patch 001
IBM WebSphere Application Server/6.0
IBM Java 1.4.2_11

I took 2 dates, a start and end date, performed a diff, then added the
diff to the start and subtracted it from the end; all BT calculations
are done in filters on the server side.  These are the results of 3 of
those tests:

Here are the scenarios I ran using the Mid-Tier (just to avoid
potential client/MS DST issues):

* Test 0
Business Time Type: Business Time 1
TestID: 109
Start: 3/10/2007 1:00:00 PM
End: 3/10/2007 2:00:00 PM
Diff Seconds: 3600
Diff Minutes: 60
Diff Hours: 1
Workday: 24 Hr Tag
Holiday: 24 Hr Tag
Result of Add to Start: 3/10/2007 2:00:00 PM (for all 3 units)
Result of Subtract from End: 3/10/2007 1:00:00 PM (for all 3 units)
* DB Values:
REQUEST_ID: 109
STARTDATE: 1173549600
ENDDATE: 1173553200
ENDDATE-STARTDATE: 3600

* Test 1
TestID: 111
Business Time Type: Business Time 1
Start: 3/11/2007 1:00:00 AM
End: 3/11/2007 3:00:00 AM
Diff Seconds: 7200
Diff Minutes: 120
Diff Hours: 2
Workday: 24 Hr Tag
Holiday: 24 Hr Tag
Result of Add to Start: 3/11/2007 3:00:00 AM (for all 3 units)
Result of Subtract from End: 3/11/2007 1:00:00 AM (for all 3 units)
* DB Values:
REQUEST_ID: 111
STARTDATE: 1173592800
ENDDATE: 1173596400
ENDDATE-STARTDATE: 3600

* Test 2
TestID: 115
Business Time Type: Business Time 1
Start: 3/11/2007 1:00:00 AM
End: 3/11/2007 2:00:00 AM
Diff Seconds: 3600
Diff Minutes: 60
Diff Hours: 1
Workday: 24 Hr Tag
Holiday: 24 Hr Tag
Result of Add to Start: 3/11/2007 2:00:00 AM (for all 3 units)
Result of Subtract from End: 3/11/2007 1:00:00 AM (for all 3 units)
* DB Values:
REQUEST_ID: 115
STARTDATE: 116478
ENDDATE: 1164783600
ENDDATE-STARTDATE: 3600

While the add and subtract put the date back at the expected values,
the diffs seem to be off for test 1 (which covers the DST switch).

For Test 1, I would expect to see 1 hour as the result of the diff
(1:00-1:59, then jump to 3:00).

This is very odd.  Can someone give me a sanity check on what I think
I should be seeing?  The same workflow was used to generate all the
test results (filters on 1 form where I provide the BT version,
holiday/workday/segments, start date, and end date).  The calculations
are done properly when using the time difference provided by the diff,
but I am concerned this will cause issues for time calculations where
the offset is provided as a constant (e.g. 3/11/2007 1:00:00 AM + 4
hours will result in 4/2/2006 5:00:00 AM, when it should result in
4/2/2006 6:00:00 AM.  The 1 hour increments would follow this pattern:
1-3, 3-4, 4-5, 5-6).

Thanks,
Axton Grams



___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers 
Are"