Views: 1821
Number of votes: 2
Average rating:

Issue with Dijit TimeTextBox in the UK

Recently a few customers in the UK reported a strange issue. They use David Knipe's solution to create a time picker with Dijit TimeTextBox, and find that the text box shows different time with 1 hour off between IE and chrome. For instance, if an editor in the UK see 8:00AM in IE, he would see 9:00AM in chrome. But It doesn't happen in other locations. If you open the same page in Sweden, you see 9:00AM for both browsers. And in Vietnam you see 3:00PM for both.

If we check the database, we would find the saved value is 1970-01-01T08:00:00.000Z. You might wonder where the date comes from since it's just a time picker. It's because when selecting the time, the widget will create a Date object, set selected time as local time, and set date to 1970-01-01. It also shows that it works on GMT in IE while on GMT+1 in chrome. It seems that chrome does not work correctly in the UK. However, according to the history of British Summer Time, from 27/10/1968 to 31/10/1971, Britain had an experiment which made the country remain on GMT+1 throughout the year. For this reason, actually chrome is correct while IE is wrong.

Since the TimeTextBox is not a widget of Episerver, we don't solve the issue in CMS UI. A quick fix could be creating a custom widget that inherits from TimeTextBox, and override two methods to set the year other than 1970. Then use it as the custom editor instead of "dijit/form/TimeTextBox". The custom widget will work on GMT in the UK for both browsers.


], function (declare, TimeTextBox) {

    return declare([TimeTextBox], {

        parse: function () {
            // summary:
            //		Sets to current year instead of 1970 to fix the inconsistency of British Time
            var value = this.inherited(arguments);
            if (value instanceof Date) {
                value.setFullYear(new Date().getFullYear());
            return value;

        _setValueAttr: function (value, priorityChange, formattedValue) {
            // summary:
            //		Sets the date on this textbox. Note: value can be a JavaScript Date literal or a string to be parsed.

            // The value is a string when loading from server. In this case do not modify the year.
            if (value instanceof Date && !this._isInvalidDate(value)) {
                value.setFullYear(new Date().getFullYear());

It is noteworthy that the TimeTextBox works with javascript Date object based on the browser time; it is timezone sensitive, and therefore, it shows a different time in different locations. However, it sets a fixed date; dojo, by default, uses 1970-01-01. As a result, it is not DST(Daylight saving time) sensitive, which means it does not change no matter whether the local time observes DST or not. This may lead to confusion. Think about this scenario: an editor in Sweden is editing the page in summer. Which timezone would be expected? Though the local timezone is CEST(GMT+2), the actual time shown in the widget is CET(GMT+1). This is because the offset is not based on the current date, but on the fixed date(1970-01-01 or whatever else).

That's why a timezone insensitive widget might be useful. You could also inherit from TimeTextBox. The idea is to display UTC time in the widget. In this case, editors always see the same UTC time regardless of the location. See the example on github.

Aug 19, 2019

David Knipe
( By David Knipe, 8/20/2019 6:15:38 AM)

Good catch on that particlar bug! Thanks for writing up, I've added some advisory text to my original blog.

( By Vincent, 8/21/2019 10:58:36 AM)

Insightful. There are two things I never get it right at beginning of each solution - Cache and DateTime. I respect your point on use UTC time editors always see the same time, but in my opinion editors should only see the time based on their profile settings on the UI similar to the forum does. 

John-Philip Johansson
( By John-Philip Johansson, 9/10/2019 11:08:22 AM)

@Vincent: The whole problem is around user time zones. For the cases where time zone isn't necessary one could use UTC to show the time. If the time zone is necessary then of course the last paragraph with the UTC suggestion is not applicable.

Please login to comment.