Alex Wang
Alex Wang  -  CMS
Aug 19, 2019
  3525
(2 votes)

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.

define([
    "dojo/_base/declare",
    "dijit/form/TimeTextBox"

], 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());
            }
            this.inherited(arguments);
        }
    });
});

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

Comments

David Knipe
David Knipe Aug 20, 2019 06:15 AM

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

Vincent
Vincent Aug 21, 2019 10:58 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
John-Philip Johansson Sep 10, 2019 11:08 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.
Latest blogs
How Optimizely Web Experimentation enables fast validation of design and UX changes

Ever wondered how to increase conversion rates and quickly validate design/UX alternatives to find the most impactful changes? I wrote a practical...

Jacob Pretorius | Jan 31, 2023

What’s next after Google Optimize’s sunsetting?

Google has announced that it is sunsetting the Google Optimize and Optimize 360 services, forcing customers to explore new platforms and invest in...

Ynze | Jan 31, 2023 | Syndicated blog

What’s next after Google Optimize’s sunsetting?

Google has announced that it is sunsetting the Google Optimize and Optimize 360 services, forcing customers to explore new platforms and invest in...

Ynze | Jan 31, 2023 | Syndicated blog

Migrating from Providers to CMS 12 ASP.NET Identity with cookie tweaks

Notes on migrating a multi-site from Membership and Role Providers to ASP.NET Identity and changing cookie options dynamically.

Johan Kronberg | Jan 30, 2023 | Syndicated blog