> It doesn't matter if you have applied the appropriate patches to the workstations and the server and the database. > This library is internal to the AR Server and will play a role. Only for web services and import/export - and for import/export this probably isn't an issue in 5.1.2 because the library is used to for XML processing of deployable apps - a feature which was added in 6.0.1. Other parts of the product use the operating system. > Please bmc, how much work could it be for you to do a v5 patch? Simply put, it would be as much work as taking AR System 6.3 and backporting it to 5.1.2. The affected libraries cannot patched and thus the code would have to be updated to use the newer libraries. Even were BMC to do this (which would take months to accomplish), the effort required by the customer to apply this "patch" would be equivalent to upgrading to AR System 6.3. Thus, it does not make sense to go down this path - either for customers or for BMC - especially recognizing the minimal impact caused by this issue within AR System 6.0.1 and previous versions. 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 Susan Palmer Sent: Tuesday, February 27, 2007 10:08 AM To: [email protected] Subject: Re: DST and Time Calculation White Paper? ** Hi Norm, After querying numerous people that have tested the DST dilemma re business time 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 internal to 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] <mailto:[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___ __20060125_______________________This posting was submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
