I'm such an idiot!
-
A few months ago, we launched a web-based timeclock Azure application. The web app uses a timezone offset from UTC application setting to derive client local time display/events. Since the inception, I have been carefully planning on how to deal with DST and yesterday being the first time change, I set aside a couple of hours to make sure it worked. The process was simple... change the web app config setting (for the timezone offset) to one less than the current setting. I tested it in development, works fine...tested on our demo/test server, works fine. So, all I needed to do on Azure was to modify the setting and restart the application...I did, and tested it and it looked fine. I was done, and felt pretty good about how smooth it went. :) Then, I get the email early this morning (the customer is a timezone ahead of us) that the timeclock was showing the wrong time! :omg: But I could swear that it was right yesterday! :confused: What was strange was that my cell phone and workstation times were different, and I just went with the cell phone time. Now I have to wait until late this afternoon when everyone is logged out of the system to figure out exactly what is wrong. I have a feeling that the 'always on' feature has prevented the new setting from taking effect. It's going to be a fun afternoon! X|
"Go forth into the source" - Neal Morse
-
A few months ago, we launched a web-based timeclock Azure application. The web app uses a timezone offset from UTC application setting to derive client local time display/events. Since the inception, I have been carefully planning on how to deal with DST and yesterday being the first time change, I set aside a couple of hours to make sure it worked. The process was simple... change the web app config setting (for the timezone offset) to one less than the current setting. I tested it in development, works fine...tested on our demo/test server, works fine. So, all I needed to do on Azure was to modify the setting and restart the application...I did, and tested it and it looked fine. I was done, and felt pretty good about how smooth it went. :) Then, I get the email early this morning (the customer is a timezone ahead of us) that the timeclock was showing the wrong time! :omg: But I could swear that it was right yesterday! :confused: What was strange was that my cell phone and workstation times were different, and I just went with the cell phone time. Now I have to wait until late this afternoon when everyone is logged out of the system to figure out exactly what is wrong. I have a feeling that the 'always on' feature has prevented the new setting from taking effect. It's going to be a fun afternoon! X|
"Go forth into the source" - Neal Morse
Everything should be stored in UTC, and be converted to/from local time in javascript using the client's timezone. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
A few months ago, we launched a web-based timeclock Azure application. The web app uses a timezone offset from UTC application setting to derive client local time display/events. Since the inception, I have been carefully planning on how to deal with DST and yesterday being the first time change, I set aside a couple of hours to make sure it worked. The process was simple... change the web app config setting (for the timezone offset) to one less than the current setting. I tested it in development, works fine...tested on our demo/test server, works fine. So, all I needed to do on Azure was to modify the setting and restart the application...I did, and tested it and it looked fine. I was done, and felt pretty good about how smooth it went. :) Then, I get the email early this morning (the customer is a timezone ahead of us) that the timeclock was showing the wrong time! :omg: But I could swear that it was right yesterday! :confused: What was strange was that my cell phone and workstation times were different, and I just went with the cell phone time. Now I have to wait until late this afternoon when everyone is logged out of the system to figure out exactly what is wrong. I have a feeling that the 'always on' feature has prevented the new setting from taking effect. It's going to be a fun afternoon! X|
"Go forth into the source" - Neal Morse
-
It also depends upon where your client is - in America, for example, Arizona does not respect DST, so a client calling in from AZ Saturday, needs the same offset he/she needs today, but others around Arizona need the -1.
In this case, all offices are in the same time zone. One of the key specs for the project was that it had to be tamper-proof for the users, so no client settings are used whatsoever except to get a difference of timezone adjusted server time and local time, used to run a javascript clock.
"Go forth into the source" - Neal Morse
-
In this case, all offices are in the same time zone. One of the key specs for the project was that it had to be tamper-proof for the users, so no client settings are used whatsoever except to get a difference of timezone adjusted server time and local time, used to run a javascript clock.
"Go forth into the source" - Neal Morse
-
Everything should be stored in UTC, and be converted to/from local time in javascript using the client's timezone. :)
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
A few months ago, we launched a web-based timeclock Azure application. The web app uses a timezone offset from UTC application setting to derive client local time display/events. Since the inception, I have been carefully planning on how to deal with DST and yesterday being the first time change, I set aside a couple of hours to make sure it worked. The process was simple... change the web app config setting (for the timezone offset) to one less than the current setting. I tested it in development, works fine...tested on our demo/test server, works fine. So, all I needed to do on Azure was to modify the setting and restart the application...I did, and tested it and it looked fine. I was done, and felt pretty good about how smooth it went. :) Then, I get the email early this morning (the customer is a timezone ahead of us) that the timeclock was showing the wrong time! :omg: But I could swear that it was right yesterday! :confused: What was strange was that my cell phone and workstation times were different, and I just went with the cell phone time. Now I have to wait until late this afternoon when everyone is logged out of the system to figure out exactly what is wrong. I have a feeling that the 'always on' feature has prevented the new setting from taking effect. It's going to be a fun afternoon! X|
"Go forth into the source" - Neal Morse
Actually did read, sounds like a fun annoying case to track and fix. Looking forward to get the results on what caused the problem when you find it. :java:
-
Actually did read, sounds like a fun annoying case to track and fix. Looking forward to get the results on what caused the problem when you find it. :java:
I finally got it working. It turns out there is a big difference between applicationSettings and appSettings in .NET! I was using the wrong one! :doh: It only seemed to be working since I was replacing the dll every time previous to this. Ah well, I learned something! :laugh:
"Go forth into the source" - Neal Morse
-
I finally got it working. It turns out there is a big difference between applicationSettings and appSettings in .NET! I was using the wrong one! :doh: It only seemed to be working since I was replacing the dll every time previous to this. Ah well, I learned something! :laugh:
"Go forth into the source" - Neal Morse
Glad that you fixed it. :thumbsup:
