Hi Susan, I second your motion and plea to BMC to provide a patch for Version 5. We plan to start implementation of version 7.x within a few weeks and it is not convenient for us to upgrade twice.
We have taken the following steps to conform to the DST changes: OS: AIX 5.2 - applied DST patches Java - Upgraded to IBM 1.4.2.125 - The Email Engine uses the JRE and Mid Tier the SDK. Environment OS: AIX 5.2 DB: Oracle 9.2.0.6.0 AR Server: 5.1.2 Patch 1494 Email Engine: 5.1.2 Patch 1494 Help Desk: 5.0 Mid Tier: Version 6.00.01 patch 1473 Is there anything else I should be paying attention to? David [from BMC], your suggestions are also welcome. Please advise. Regards, Audrey Franklin New York University [EMAIL PROTECTED] ----- Original Message ----- From: Susan Palmer <[EMAIL PROTECTED]> Date: Tuesday, February 27, 2007 1:07 pm Subject: Re: DST and Time Calculation White Paper? > Hi Norm, > > After querying numerous people that have tested the DST dilemma re > businesstime calculations the explanation that seems to make the > most sense boils > down to this. And I apologize if all the words are not exactly > right but I > was having a hard time getting my arms around it too. I couldn't test > because we already have our dev server at v7 and did not have > plans to do > production before 3/11. So I'm relying on other's information. > > Apparently with v5.x a 'library' was added that in effect defines > the DST > start and end dates. The focus was mainly on v6 and v7 with a scan > reference to v5 since v5 is no longer 'supported'. It appears > this library > was not in the AR Server before v5 but I do not have a > confirmation on that. > > > Since that 'library' is there all business time calculations at > some point > reference it to determine how it should calculate. Since there's > no patch > for v5 we are forced to upgrade. > > My belief is that since this is an extraordinary situation a patch > for v5 > should be provided. There are quite a few people still on it > since v7 is > relatively new. I understand the need to keep a certain level of > support in > control but this is not the norm and preparation time has been > minimal. > It doesn't matter if you have applied the appropriate patches to > the workstations and the server and the database. This library is > internalto the AR Server and will play a role. > > I have one critical calculation that is of concern. There are > other calcs > but if they are off an hour for a few weeks everyone will live > through it. > The reason we haven't finished our upgrade on the production > server is a > resource issue here. Well, it's worse now with all the systems > that need > something done to them! A patch would be so much easier. > > Please bmc, how much work could it be for you to do a v5 patch? > There are > allot of customers out here that would be grateful. It would > provide a > great deal of good will. > > Thanks, > Susan > > 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 > > > Susan Palmer > ShopperTrak > 200 W Monroe St 11th Floor > Chicago, IL 60606 > Office: 312-529-5325 > Cell: 302-502-7687 > [EMAIL PROTECTED] > > > > On 2/27/07, Kaiser Norm E CIV USAF 96 CG/SCWOE > <[EMAIL PROTECTED]>wrote: > > > > ** > > > > Hi all: > > > > > > > > I'm still trying to wrap my head around all the DST > ramifications for > > 5.1.2, and I guess I'm thinking it would help if I had a > technical white > > paper or other document that specifies exactly how Remedy 5.1.2 > calculates> time and time conversions. > > > > > > > > Here's my thinking: > > > > > > > > The Remedy server stores all time values as Unix time, which is > the total > > of seconds since 1 January 1970 GMT. Time values, then, get > stored in a > > number field in the database (as opposed to a date/time field). > > Accordingly, if a user passes a date and time in a search query, > Remedy must > > convert the date and time supplied by the user to the equivalent > Unix time. > > It must do this by first adding or subtracting the appropriate > number of > > hours based on the time zone and then possibly add an hour for DST. > > > > > > > > If you run such a query, which piece of Remedy does this > conversion before > > the query is passed to the underlying database? Is it the server > or the > > client? Does the client do the time conversion before the query > is passed to > > the server or does the client just pass the query to the server > as-is and > > the server does the time conversion? > > > > > > > > If the server does the time conversion, is it saying, "OK, I got > a time > > value in this query I'm to execute. So let me convert the time > to something > > I truly understand. So let's see now…what time zone am I in…and > are we > > observing daylight savings time?" I assume, then, that the > server queries > > the operating system for the timezone??? And does it query the > operating> system for whether or not the time zone is currently > observing DST? It > > can't, in my mind, otherwise there wouldn't be a bug. It must be > > calculating whether or not DST is being observed itself based on > its own > > internal date/time algorithm? Yes? > > > > > > > > Does anyone know the answers to these issues or know of a > whitepaper that > > definitively describes how Remedy calculates time? > > > > > > > > Thanks, > > > > Norm > > __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"
