Thank you, Congress. Thank you so much!
Since our Government, in their divine wisdom, decided to change when Daylight Saving Time starts and ends, my life has become hell.
While most things went off without a hitch, we’ve run into a few issues that defy correction.
Currently, the thing which is the bane of my existence is the system I flew to Boston last year to set up (you can read it’s multi part drama here). Somewhere in the system, it appears that the dates for DST have been hard coded, and finding it has been difficult.
I had found something in the database for the application and, after modifying it, thought that the issue was fixed:
CUST_TZ_CD ISO_8601_TZ_CD —————————— —————————— America/Anchorage AKST+9AKDT,M4.1.0/2,M10.5.0/2 America/Chicago CST+6CDT,M4.1.0/2,M10.5.0/2 America/Dawson_Creek MST+7 America/Denver MST+7MDT,M4.1.0/2,M10.5.0/2 America/Edmonton MST+7MDT,M4.1.0/2,M10.5.0/2 America/Halifax AST+4ADT,M4.1.0/2,M10.5.0/2 America/Indianapolis EST+5 America/Montreal EST+5EDT,M4.1.0/2,M10.5.0/2 America/Phoenix MST+7 America/Vancouver PST+8PDT,M4.1.0/2,M10.5.0/2 America/Winnipeg CST+6CDT,M4.1.0/2,M10.5.0/2 America/Los_Angeles PST+8PDT,M4.1.0/2,M10.5.0/2 America/New_York EST+5EDT,M4.1.0/2,M10.5.0/2
If you don’t understand what that all means, you can read this.
After making the modifications (changing it to read xxxxxxxx,M3.2.0/2,M11.1.0/2) I had hoped that it would propagate the correct offset down to the endpoints.
I thought wrong.
We’ve updated Weblogic, Java, and the servers, but to no avail.
So…. it’s still off by an hour, and the end users are getting grumbly because their schedules are off.
*sigh*
It would be nice if the company that wrote the application, designed and configured the hardware, etc., was still in business… but they’re not. So, we’re on our own, supporting that which has no other support, and blindly plowing our way through it. It’s not that we (and when I say “we”, I mean “I”) don’t know anything about the system in question, it’s just that I’m unsure as to where the issue might be.
Of course, none of this would be an issue if they hadn’t changed DST (or if they had changed it next year, when this program has ended and the system was shut down).
2 comments2 Comments so far
One thing I’m still trying to get my head around on DST… this doesn’t change the GMT offset, does it? So PST is really a modified PST. For example, its not a MST until November, or the other way around (-7)? Clear as mud?
No, the offset doesn’t change (other that the change one would expect during DST). Therefore, that part of the line doesn’t need to be modified.
The first half of the entry in the TZ: America/Vancouver PST+8PDT,M3.2.0/2,M11.1.0/2 can be read like this:
+8 is the normal offset from GMT (or UTC), M3 = month 3 (March), 2 = 2nd week, 0 = sunday, 2 = the time that the change occurs.
In a nutshell, it says that on the 2nd week of March, on Sunday at 2:00 am, change the clock. Change it back on Sunday of the first week of November at 2:00 am.
And yes… I am geek to the bone.