User Tools

Site Tools


why_did_time_change_in_the_wrong_month

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
why_did_time_change_in_the_wrong_month [2019/07/25 03:28] mmacgregorwhy_did_time_change_in_the_wrong_month [2019/07/25 03:39] (current) mmacgregor
Line 1: Line 1:
-This is a work in progress 
  
 ====== Why did the system time change in the wrong month? ====== ====== Why did the system time change in the wrong month? ======
  
-There are a variety of reasons that may explain this situation and before we discuss the other possibilities, we're going to explore a change that the US Congress made to the rules.  In the Energy Policy Act of 2005, the US Congress agreed to change when the semi-annual time changes would occur, starting January 1, 2007.  +There are a variety of reasons that may explain this situation and before we discuss the other possibilities, we're going to explore a change that the US Congress made to the rules.  In the Energy Policy Act of 2005((1 Energy Policy Act of 2005: https://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005)), the US Congress agreed to change when the semi-annual time changes would occur, starting January 1, 2007.  
  
-Prior to that change, the  Public Utility Holding Company Act of 1935 dictated that time would change within the US as follows The first Sunday of April at 2 a.m and the final Sunday of October at 2 a.m.  +Prior to that change, the  Public Utility Holding Company Act of 1935((2 Public Utility Holding Company Act of 1935: https://en.wikipedia.org/wiki/Public_Utility_Holding_Company_Act_of_1935)) dictated that time would change within the US as follows The first Sunday of April at 2 a.m and the final Sunday of October at 2 a.m.  
  
 After the change, the rules changed to to the second Sunday of March at 2 a.m. and the first Sunday of November at 2 a.m. After the change, the rules changed to to the second Sunday of March at 2 a.m. and the first Sunday of November at 2 a.m.
  
-The HP OpenVMS engineering group made the decision to provide patches for some versions of OpenVMS, but not all of them. Thus, several did methods were necessary to cover every OpenVMS version+The HP OpenVMS engineering group made the decision to provide patches for some versions of OpenVMS, but not all of them. Thus, several different methods were necessary to cover every OpenVMS version.
- +
-Any VMS version listed below before OpenVMS 8.4 are officially *UNSUPPORTED*.  The solutions listed below are for your benefit, PARSEC cannot guarantee its effectiveness because of the possibility of error in transmitting or implementing it.  It is meant to be used as a template for writing your own solution, and it may require modification for use on your system.+
  
 +The solutions listed below are for your benefit, PARSEC cannot guarantee its effectiveness because of the possibility of error in transmitting or implementing it.  It is meant to be used as a template for writing your own solution, and it may require modification for use on your system.
  
 NOTES: NOTES:
Line 18: Line 16:
 If the VMS version is not listed below and you have questions, then log a call with PARSEC at 866-3-PARSEC and we'll find a solution for you. If the VMS version is not listed below and you have questions, then log a call with PARSEC at 866-3-PARSEC and we'll find a solution for you.
  
-All of the TZ patches imply that a reboot is not necessary.  This is officially correct, but perhaps misleading.  If you are alpha 7.3 or higher, and you are using the AUTO_DLIGHT_SAV option, then there is a TQE in existance under the JOB_CONTROL process that is currently set to go off in April instead of in March.  Thus, you will either need to stop/restart the JOB_CONTROL process (something we don't really recommend on busy machines, but power users can decide if they can go that route), or reboot the machine.  Either of these steps will correct the TQEs that kick off.+All of the TZ patches imply that a reboot is not necessary.  This is officially correct, but perhaps misleading.  If you are alpha 7.3 or higher, and you are using the AUTO_DLIGHT_SAV option, then there is a TQE in existence under the JOB_CONTROL process that is currently set to go off in April instead of in March or November instead of October.  Thus, you will either need to stop/restart the JOB_CONTROL process (something we don't really recommend on busy machines, but power users can decide if they can go that route), or reboot the machine.  Either of these steps will correct the TQEs that kick off.
  
 All examples below are based on Eastern time.  You will need to modify rules according to your own timezone.  If you aren't sure what the rule should read, contact PARSEC at 866-3-PARSEC All examples below are based on Eastern time.  You will need to modify rules according to your own timezone.  If you aren't sure what the rule should read, contact PARSEC at 866-3-PARSEC
Line 205: Line 203:
 The solution is already build into the OpenVMS codestream. The solution is already build into the OpenVMS codestream.
 </code> </code>
 +
 +The above information is specific to perhaps using the wrong timezone rules for your system.  If that doesn't seem to address the issue, then log a call with PARSEC at 866-3-PARSEC and we'll be happy to assist you.
  
why_did_time_change_in_the_wrong_month.txt · Last modified: 2019/07/25 03:39 by mmacgregor

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki