I'm using a TextBox/CalendarExtender to enter a date that's databound to a database. When I published the site to my production server (three hours earlier due to time zone), the date displayed in the TextBox that's manipulated by the CalendarExtender is decremented by one.
In the attached file, there are two TextBoxes. The first is just a plain TextBox, the second has a CalendarExtender attached to it. In the Page_Load handler I'm populating both TextBoxes and the CalendarExtender' SelectedDate property with that date (note I'm using Feb 1, 2008 for the example, but it's arbitrary).
This works great if you run it on a computer configured for that timezone or eastward. But if you go west, the second textbox is initialized with the previous day. Experiments in formatting indicate that the time associated with both TextBoxes is 00:00:00.000
This has become a show-stopper for me. My host server is on the East Coast, I'm on the West Coast. CalendarExtender loses an hour and I can't work around it!
Steps To Recreate: Host the attached file on one machine. On another computer (or Virtual PC instance), set the timezone to be at least one hour later (go west, i.e. from UTC-8 to UTC-9 or UTC-10). The second TextBox is initialized with 1/31/2008 instead of 2/1/2008!
Comments: There really seems to be s.th. wrong with time zones in CalendarExtender: The selected date is sometimes not highlighted correctly. When trying to find out why, I noticed a lot of conversion to and from UTC in CalendarExtender's source code. But why should that be necessary at all? The calendar always runs on client machines in any time zone, so it should actually not care about UTC except when reading an input from user or from server. The server, on the other hand, should of course respect UTC and the user's time zone offset, to know which exact date is meant on postback. IMHO it should simply work like this: When the CalendarExtender reads a date from its associated TextBox, it should assume a local date/time unless a different UTC offset is specified in the TextBox and matches the format string. The result, i.e. the _selectedDate property, should always be the corresponding *local* date and time. Example: The client computer may be configured with german Culture/UICulture in timezone UTC+1. If the user enters "31.12.2012 23:30 UTC", then CalendarExtender should once convert it to the corresponding local date "01.01.2013 00:30 UTC+1" and highlight january 1st 2013 as selected date, because that's what "31.12.2012 23:30 UTC" actually means for the user. If the user just enters "01.01.2013 00:30", then this date should be assumed local (missing offset) and the highlighted date should be the same as above. Thus, there would be no need for these getUTC..() calls all over the code and the Calendar would always display what the user expects. But instead, it works like this: _selectedDate holds 01.01.2013 00:30 UTC+1 (german culture), and the calender highlights 31.12.2012, which is the corresponding UTC date and thus a bit wrong from the user's point of view, whose computer is configured for UTC+1 after all.
In the attached file, there are two TextBoxes. The first is just a plain TextBox, the second has a CalendarExtender attached to it. In the Page_Load handler I'm populating both TextBoxes and the CalendarExtender' SelectedDate property with that date (note I'm using Feb 1, 2008 for the example, but it's arbitrary).
This works great if you run it on a computer configured for that timezone or eastward. But if you go west, the second textbox is initialized with the previous day. Experiments in formatting indicate that the time associated with both TextBoxes is 00:00:00.000
This has become a show-stopper for me. My host server is on the East Coast, I'm on the West Coast. CalendarExtender loses an hour and I can't work around it!
Steps To Recreate: Host the attached file on one machine. On another computer (or Virtual PC instance), set the timezone to be at least one hour later (go west, i.e. from UTC-8 to UTC-9 or UTC-10). The second TextBox is initialized with 1/31/2008 instead of 2/1/2008!
Comments: There really seems to be s.th. wrong with time zones in CalendarExtender: The selected date is sometimes not highlighted correctly. When trying to find out why, I noticed a lot of conversion to and from UTC in CalendarExtender's source code. But why should that be necessary at all? The calendar always runs on client machines in any time zone, so it should actually not care about UTC except when reading an input from user or from server. The server, on the other hand, should of course respect UTC and the user's time zone offset, to know which exact date is meant on postback. IMHO it should simply work like this: When the CalendarExtender reads a date from its associated TextBox, it should assume a local date/time unless a different UTC offset is specified in the TextBox and matches the format string. The result, i.e. the _selectedDate property, should always be the corresponding *local* date and time. Example: The client computer may be configured with german Culture/UICulture in timezone UTC+1. If the user enters "31.12.2012 23:30 UTC", then CalendarExtender should once convert it to the corresponding local date "01.01.2013 00:30 UTC+1" and highlight january 1st 2013 as selected date, because that's what "31.12.2012 23:30 UTC" actually means for the user. If the user just enters "01.01.2013 00:30", then this date should be assumed local (missing offset) and the highlighted date should be the same as above. Thus, there would be no need for these getUTC..() calls all over the code and the Calendar would always display what the user expects. But instead, it works like this: _selectedDate holds 01.01.2013 00:30 UTC+1 (german culture), and the calender highlights 31.12.2012, which is the corresponding UTC date and thus a bit wrong from the user's point of view, whose computer is configured for UTC+1 after all.