On my one critical calculation (the others are not critical) I do the difference between two date/time and produce a result in hours. In this case it really doesn't matter if I patch or not because even if the time is off it will be off the same amount on both date/times. I think that seems to make sense .... any feedback on that thought?
Susan On 2/27/07, Easter, David <[EMAIL PROTECTED]> wrote:
** > Then the only thing I need to do besides patching the OS is to patch the 6.3 mid-tier. Thanks for the clarification. I did not say that. My response was to whether the Mid-Tier uses the 3rd party library for DST calculations in 6.0.1. In 6.0.1 it does not use that library. In 6.3 and 7.0.01 it does. I made no statement to "just patch the 6.3 mid-tier". 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 *strauss *Sent:* Tuesday, February 27, 2007 11:48 AM *To:* arslist@ARSLIST.ORG *Subject:* Re: DST and Time Calculation White Paper? ** Then the only thing I need to do besides patching the OS is to patch the 6.3 mid-tier. Thanks for the clarification. Christopher Strauss, Ph.D. Remedy Database Administrator University of North Texas Computing Center http://remedy.unt.edu/helpdesk/ ------------------------------ *From:* Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] *On Behalf Of *Easter, David *Sent:* Tuesday, February 27, 2007 1:07 PM *To:* arslist@ARSLIST.ORG *Subject:* Re: DST and Time Calculation White Paper? ** > the impact of the DST bug on 5.1.2 systems is that times on the Midtier will be wrong, That is incorrect. Only the Mid-Tier on AR System 6.3 and 7.0.01 are affected. The Mid-Tier on 6.0.1 and previous releases is not affected if you've updated your Java versions to the recommended levels. -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 *Kaiser Norm E CIV USAF 96 CG/SCWOE *Sent:* Tuesday, February 27, 2007 10:39 AM *To:* arslist@ARSLIST.ORG *Subject:* Re: DST and Time Calculation White Paper? ** Agreed—a patch would be really nice, but I seriously don't think we're going to get one. If everything I've read is correct, the impact of the DST bug on 5.1.2systems is that times on the Midtier will be wrong, times in web services will be wrong, and times reported for import and exports will be wrong. If that's correct, that doesn't sound earth shattering. In fact, it sounds as if 99% of users won't even notice. Thoughts? ------------------------------ *From:* Action Request System discussion list(ARSList) [mailto: [EMAIL PROTECTED] *On Behalf Of *Susan Palmer *Sent:* Tuesday, February 27, 2007 12:08 PM *To:* arslist@ARSLIST.ORG *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]> 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___ __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___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
