<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic daylight_savings.com deassigns sys$timezone_name in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/daylight-savings-com-deassigns-sys-timezone-name/m-p/4299408#M91704</link>
    <description>Hi,&lt;BR /&gt;  I have a program on my system that needs to know the GMT offset for the current time zone.  In trying to adhere to the KISS principal, I made the program retrieve the value of the SYS$TIMEZONE_NAME logical and set it to the correct offset if the value was EDT or EST.  It was summer when I wrote the program, so I was quite surprised today to find out that when DST ends, the logical doesn't get changed, it just gets deassigned.  Is there a reason for this?  Is there a way to make it be correctly defined throughout the year?  I'm working on VMS 7.3-2.</description>
    <pubDate>Mon, 03 Nov 2008 18:09:19 GMT</pubDate>
    <dc:creator>sharon conger</dc:creator>
    <dc:date>2008-11-03T18:09:19Z</dc:date>
    <item>
      <title>daylight_savings.com deassigns sys$timezone_name</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/daylight-savings-com-deassigns-sys-timezone-name/m-p/4299408#M91704</link>
      <description>Hi,&lt;BR /&gt;  I have a program on my system that needs to know the GMT offset for the current time zone.  In trying to adhere to the KISS principal, I made the program retrieve the value of the SYS$TIMEZONE_NAME logical and set it to the correct offset if the value was EDT or EST.  It was summer when I wrote the program, so I was quite surprised today to find out that when DST ends, the logical doesn't get changed, it just gets deassigned.  Is there a reason for this?  Is there a way to make it be correctly defined throughout the year?  I'm working on VMS 7.3-2.</description>
      <pubDate>Mon, 03 Nov 2008 18:09:19 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/daylight-savings-com-deassigns-sys-timezone-name/m-p/4299408#M91704</guid>
      <dc:creator>sharon conger</dc:creator>
      <dc:date>2008-11-03T18:09:19Z</dc:date>
    </item>
    <item>
      <title>Re: daylight_savings.com deassigns sys$timezone_name</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/daylight-savings-com-deassigns-sys-timezone-name/m-p/4299409#M91705</link>
      <description>I've been involved in this discussion for twenty years now, and with the various oddities involved in TZ and DST over that time.&lt;BR /&gt;&lt;BR /&gt;The daylight_savings.com (sic; it's "daylight saving") tool is probably broken here.  Check for ECO kits; there have been various kits here.  If not current, get there.&lt;BR /&gt;&lt;BR /&gt;The following will probably fix this case:&lt;BR /&gt;&lt;BR /&gt;$ @sys$manager:utc$time_setup&lt;BR /&gt;&lt;BR /&gt;IMHO, the TZ and DST features will never work entirely right on OpenVMS, pending fundamental architectural changes.   These architectural changes will probably break some existing software, so they're comparatively unlikely; we'll continue along with the semiannual festivals of weird TZ and DST values for the foreseeable future.  There are just too many assumptions and hacks and stuff that looks at random logical names to ever get this working "right."&lt;BR /&gt;&lt;BR /&gt;If you want the best operation, run UTC and forget DST.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Mon, 03 Nov 2008 19:30:19 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/daylight-savings-com-deassigns-sys-timezone-name/m-p/4299409#M91705</guid>
      <dc:creator>Hoff</dc:creator>
      <dc:date>2008-11-03T19:30:19Z</dc:date>
    </item>
  </channel>
</rss>

