Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 27 replies
  • Subscribers 3 subscribers
  • Views 10286 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DST Change

MarkMurphy
Anyone know if Version 6.X has been patched for the new US/Canada time zone change??


This thread was automatically locked due to age.
Parents
  • 0
    Nope.  It sure hasn't.  Nice of them to think about us, don't you think?
  • 0 in reply to jfreed
    Nope.  It sure hasn't.  Nice of them to think about us, don't you think?


    Nice attitude [;)]

    I contacted support a while back about this. The following is me paraphrasing what they told me: They aren't releasing an update for V5 that would address the DST change. They were, at the time, working on the V6 update. V7's already compliant.

    We're still on V5. So I think it's either change it by hand, or try something like this:

    #!/bin/sh

    wget 'elsie.nci.nih.gov/.../tzdata2007c.tar.gz'
    mkdir -p /tmp/tzdata
    tar xf ./tzdata2007c.tar.gz -C /tmp/tzdata
    cd /tmp/tzdata
    zic -d /tmp/zoneinfo northamerica
    cp /tmp/zoneinfo/EST5EDT /usr/share/zoneinfo/
    cp -r /tmp/zoneinfo/America/* /usr/share/zoneinfo/America/
    ln -fs /etc/localtime /usr/share/zoneinfo/EST5EDT
    zdump -v /usr/share/zoneinfo/EST5EDT | grep 2007
    echo '------------------------'
    zdump -v /usr/share/zoneinfo/America/New_York | grep 2007
    echo '------------------------'
    zdump -v /etc/localtime | grep 2007
    cd /tmp
    rm -rf zoneinfo/ tzdata/
    echo "Update completed"


    Which I've not done, because tho I think it'd fix the issue I don't have a dev-environment v5 system setup to test it with.
  • 0 in reply to shanez
    Thanks for the info shanez.

    Here's another thread with more info:

    Daylight Savings Time and Energy Policy Act of 2005

    I would suggest replacing the timezone files manually as then when/if Astaro does update the timezone data, you won't run into conflicts as if you had installed a new timezone RPM as mentioned in the other thread.

    We are getting ready to start testing our own fix as well since it appears that we can't count on Astaro to fix this issue.

    Is V5 still officially supported? If so, I'm very surprised that they are not willing to fix this issue on that platform. RedHat has released timezone updates for RHEL 2.1, 3 and 4.
  • 0 in reply to drees
    with v7 out v5 is going to go away....the not fixing v5's timezone issue is the first sign..time to move to v6 or another product.
  • 0 in reply to William Warren
    Now granted I have no "right" to open a trouble ticket since I just have a lowly home license, but I submitted a trouble ticket on this last night:

    Here's what I entered:

    With less than a week before Daylight Savings Time is to start for the United States and Canada (Sunday, March 11 @ 2am), there have been no patches from Astaro to deal with this VERY important change.

    As I use ASL as an SMTP proxy I can definitely see where time stamps will be at issue.

    This change in start/end dates for Daylight Savings Time was put into law in 2005. I know that people have posted questions about it in the forums, yet there have been no patches.


    Here's what I received back this AM:
    V7 has the necessary packages to apply for this change. Currently there is not a patch for v6 but I believe one is being tested.

    I apologize for being unable to resolve this issue with you at this time as our licensing records indicate that your license is for "Home Use only", this support service is for our commercial customers only. For Home Users we provide several online resources such as our knowledgebase www.astaro.com/kb and our UBB www.astaro.org. You're my.astaro.com license show as current. If you wish to purchase commercial licensing please contact the sales office or a representative in your area.

    For evaluation assistance please contact one of our sales representatives who can assist in scheduling time with an application engineer or who can place you in contact with one of Astaro's consulting partners in your area.

    Now if I was responsible for deploying a major product like a FIREWALL, I would certainly like the chance to test any patches before just putting them blindly into production, lest they turn out to either (1) not work or (2) cause instability (V7, anyone??).
  • 0 in reply to Gregg_01
    I completely agree that this is long overdue, but I would like to point out that instability is unlikely.
    (Assuming the only changes are the TZ files and whatever TZ data GLIBC has.)

    Assuming the up2date installs, and the system is restarted, it will either work, or it won't... there will be no in-between.

    Of course, if it doesn't work, and there's no rollback, life will suck this weekend. [:P]

    Barry
Reply
  • 0 in reply to Gregg_01
    I completely agree that this is long overdue, but I would like to point out that instability is unlikely.
    (Assuming the only changes are the TZ files and whatever TZ data GLIBC has.)

    Assuming the up2date installs, and the system is restarted, it will either work, or it won't... there will be no in-between.

    Of course, if it doesn't work, and there's no rollback, life will suck this weekend. [:P]

    Barry
Children