New timezone daylight savings rule for 2007 - VMS

This is a discussion on New timezone daylight savings rule for 2007 - VMS ; This is probably really an enhancement request more than a query. VMS 7.3-2, MN 4.4A I copied timezones.dat to timezones.local and inserted a new line that defined the start and end dates for use in the US beginning this new ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: New timezone daylight savings rule for 2007

  1. New timezone daylight savings rule for 2007

    This is probably really an enhancement request more than a query.

    VMS 7.3-2, MN 4.4A

    I copied timezones.dat to timezones.local and inserted a new line that
    defined the start and end dates for use in the US beginning this new
    year. The start time is specified as the second sunday of March,
    so the added line was
    Rule US 2007 DST 1:00 Second Sunday March 2:00 Last
    Sunday November

    but a $Multinet Set/timezone/select=("US/PACIFIC")
    PST/file=multinet:timezones.local

    returned: "SECOND" is not a day number, Bad DST Starting time.

    So I just hard coded it to the 11th of March. So I'm good for this
    year.

    Roger, Harvey Mudd College


  2. Re: New timezone daylight savings rule for 2007


    "wa6zvp" wrote in message
    news:1167753633.770396.303440@s34g2000cwa.googlegr oups.com...
    >
    > Richard Whalen wrote:
    > > The parser only recognizes "FIRST" and "LAST".
    > > To get second you have to use
    > >
    > > Rule US 2007 DST 1:00 Sunday >= 8 March 2:00
    > > First Sunday November 2:00
    > >
    > > For those of you that are making this change, your timezones.local file

    must
    > > have the Zone lines
    > > as well as the above rule. You'll want to remove the "COMPILED_IN" from

    the
    > > timezones.local file when you copy the rules from timezones.dat
    > >

    >
    > "COMPILED_IN" only appears in the ZONE definitions, not the RULES
    > section, so
    > that it would need to removed only in the ZONE that is in use.
    > Correct?
    >
    > Since the ZONE definition itself hasn't changed, why does one need to
    > remove
    > it at all? Perhaps the ZONE and RULES are merged when compiled in so
    > the
    > change in rules would be skipped otherwise? Just a little unclear to
    > me.
    >
    > Roger
    >



    The code that processes the timezone rules expects the ZONE and RULE lines
    to be in a single file. We learned this while experimenting to determine
    what changes would be necessary for the upcoming change to the daylight
    saving time rules.

    An official statement on how to update systems for the change will be posted
    to the MultiNet Announce email list before the end of the month.



  3. Re: New timezone daylight savings rule for 2007

    Richard Whalen wrote:
    >
    > "wa6zvp" wrote in message
    > news:1167753633.770396.303440@s34g2000cwa.googlegr oups.com...
    > >
    > > Richard Whalen wrote:
    > > > The parser only recognizes "FIRST" and "LAST".
    > > > To get second you have to use
    > > >
    > > > Rule US 2007 DST 1:00 Sunday >= 8 March 2:00
    > > > First Sunday November 2:00
    > > >
    > > > For those of you that are making this change, your timezones.local file

    > must
    > > > have the Zone lines
    > > > as well as the above rule. You'll want to remove the "COMPILED_IN" from

    > the
    > > > timezones.local file when you copy the rules from timezones.dat
    > > >

    > >
    > > "COMPILED_IN" only appears in the ZONE definitions, not the RULES
    > > section, so
    > > that it would need to removed only in the ZONE that is in use.
    > > Correct?
    > >
    > > Since the ZONE definition itself hasn't changed, why does one need to
    > > remove
    > > it at all? Perhaps the ZONE and RULES are merged when compiled in so
    > > the
    > > change in rules would be skipped otherwise? Just a little unclear to
    > > me.
    > >
    > > Roger
    > >

    >
    > The code that processes the timezone rules expects the ZONE and RULE lines
    > to be in a single file. We learned this while experimenting to determine
    > what changes would be necessary for the upcoming change to the daylight
    > saving time rules.
    >
    > An official statement on how to update systems for the change will be posted
    > to the MultiNet Announce email list before the end of the month.


    Could someone post that info here, on openvms.org and to comp.os.vms as well?

    T'would be helpful.

    --
    David J Dachtera
    dba DJE Systems
    http://www.djesys.com/

    Unofficial OpenVMS Marketing Home Page
    http://www.djesys.com/vms/market/

    Unofficial Affordable OpenVMS Home Page:
    http://www.djesys.com/vms/soho/

    Unofficial OpenVMS-IA32 Home Page:
    http://www.djesys.com/vms/ia32/

    Unofficial OpenVMS Hobbyist Support Page:
    http://www.djesys.com/vms/support/

  4. Re: New timezone daylight savings rule for 2007

    The parser only recognizes "FIRST" and "LAST".
    To get second you have to use

    Rule US 2007 DST 1:00 Sunday >= 8 March 2:00
    First Sunday November 2:00

    For those of you that are making this change, your timezones.local file must
    have the Zone lines
    as well as the above rule. You'll want to remove the "COMPILED_IN" from the
    timezones.local file when you copy the rules from timezones.dat

    "wa6zvp" wrote in message
    news:1167710224.557989.56140@v33g2000cwv.googlegro ups.com...
    > This is probably really an enhancement request more than a query.
    >
    > VMS 7.3-2, MN 4.4A
    >
    > I copied timezones.dat to timezones.local and inserted a new line that
    > defined the start and end dates for use in the US beginning this new
    > year. The start time is specified as the second sunday of March,
    > so the added line was
    > Rule US 2007 DST 1:00 Second Sunday March 2:00 Last
    > Sunday November
    >
    > but a $Multinet Set/timezone/select=("US/PACIFIC")
    > PST/file=multinet:timezones.local
    >
    > returned: "SECOND" is not a day number, Bad DST Starting time.
    >
    > So I just hard coded it to the 11th of March. So I'm good for this
    > year.
    >
    > Roger, Harvey Mudd College
    >




  5. Re: New timezone daylight savings rule for 2007


    Richard Whalen wrote:
    > The parser only recognizes "FIRST" and "LAST".
    > To get second you have to use
    >
    > Rule US 2007 DST 1:00 Sunday >= 8 March 2:00
    > First Sunday November 2:00
    >
    > For those of you that are making this change, your timezones.local file must
    > have the Zone lines
    > as well as the above rule. You'll want to remove the "COMPILED_IN" from the
    > timezones.local file when you copy the rules from timezones.dat
    >


    "COMPILED_IN" only appears in the ZONE definitions, not the RULES
    section, so
    that it would need to removed only in the ZONE that is in use.
    Correct?

    Since the ZONE definition itself hasn't changed, why does one need to
    remove
    it at all? Perhaps the ZONE and RULES are merged when compiled in so
    the
    change in rules would be skipped otherwise? Just a little unclear to
    me.

    Roger


  6. Re: New timezone daylight savings rule for 2007


    "wa6zvp" wrote in message
    news:1167753633.770396.303440@s34g2000cwa.googlegr oups.com...
    >
    > Richard Whalen wrote:
    > > The parser only recognizes "FIRST" and "LAST".
    > > To get second you have to use
    > >
    > > Rule US 2007 DST 1:00 Sunday >= 8 March 2:00
    > > First Sunday November 2:00
    > >
    > > For those of you that are making this change, your timezones.local file

    must
    > > have the Zone lines
    > > as well as the above rule. You'll want to remove the "COMPILED_IN" from

    the
    > > timezones.local file when you copy the rules from timezones.dat
    > >

    >
    > "COMPILED_IN" only appears in the ZONE definitions, not the RULES
    > section, so
    > that it would need to removed only in the ZONE that is in use.
    > Correct?
    >
    > Since the ZONE definition itself hasn't changed, why does one need to
    > remove
    > it at all? Perhaps the ZONE and RULES are merged when compiled in so
    > the
    > change in rules would be skipped otherwise? Just a little unclear to
    > me.
    >
    > Roger
    >



    The code that processes the timezone rules expects the ZONE and RULE lines
    to be in a single file. We learned this while experimenting to determine
    what changes would be necessary for the upcoming change to the daylight
    saving time rules.

    An official statement on how to update systems for the change will be posted
    to the MultiNet Announce email list before the end of the month.



  7. Re: New timezone daylight savings rule for 2007

    Richard Whalen wrote:
    >
    > "wa6zvp" wrote in message
    > news:1167753633.770396.303440@s34g2000cwa.googlegr oups.com...
    > >
    > > Richard Whalen wrote:
    > > > The parser only recognizes "FIRST" and "LAST".
    > > > To get second you have to use
    > > >
    > > > Rule US 2007 DST 1:00 Sunday >= 8 March 2:00
    > > > First Sunday November 2:00
    > > >
    > > > For those of you that are making this change, your timezones.local file

    > must
    > > > have the Zone lines
    > > > as well as the above rule. You'll want to remove the "COMPILED_IN" from

    > the
    > > > timezones.local file when you copy the rules from timezones.dat
    > > >

    > >
    > > "COMPILED_IN" only appears in the ZONE definitions, not the RULES
    > > section, so
    > > that it would need to removed only in the ZONE that is in use.
    > > Correct?
    > >
    > > Since the ZONE definition itself hasn't changed, why does one need to
    > > remove
    > > it at all? Perhaps the ZONE and RULES are merged when compiled in so
    > > the
    > > change in rules would be skipped otherwise? Just a little unclear to
    > > me.
    > >
    > > Roger
    > >

    >
    > The code that processes the timezone rules expects the ZONE and RULE lines
    > to be in a single file. We learned this while experimenting to determine
    > what changes would be necessary for the upcoming change to the daylight
    > saving time rules.
    >
    > An official statement on how to update systems for the change will be posted
    > to the MultiNet Announce email list before the end of the month.


    Could someone post that info here, on openvms.org and to comp.os.vms as well?

    T'would be helpful.

    --
    David J Dachtera
    dba DJE Systems
    http://www.djesys.com/

    Unofficial OpenVMS Marketing Home Page
    http://www.djesys.com/vms/market/

    Unofficial Affordable OpenVMS Home Page:
    http://www.djesys.com/vms/soho/

    Unofficial OpenVMS-IA32 Home Page:
    http://www.djesys.com/vms/ia32/

    Unofficial OpenVMS Hobbyist Support Page:
    http://www.djesys.com/vms/support/

+ Reply to Thread