Alex Wang
Alex Wang  -  CMS
Aug 19, 2019
visibility 5747
star star star star star
(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.

error Please login to comment.
Latest blogs
Architecting an Enterprise-Grade Development Pipeline in Optimizely SaaS CMS

Most enterprise teams show up to Optimizely SaaS CMS with a clear roadmap for their release pipeline: DEV → QA → Stage → Prod. Four logical...

Vipin Banka | Jul 12, 2026

Bynder DAM Connector for Optimizely SaaS CMS: Improved Metadata Property Synchronization

While working with the Bynder DAM Connector for Optimizely SaaS CMS , one of the key areas I explored was how Bynder asset metadata is synchronized...

Vipin Banka | Jul 11, 2026

Optimizely DXP: Every Supported Culture, One Searchable Page

Quick one for anyone building multi-language sites on Optimizely DXP. I put together a reference tool listing all 806 supported cultures. More...

Adnan Zameer | Jul 10, 2026 |

A day in the life of an Optimizely OMVP: London Meetup 2026

On 2nd July 2026 the Optimizely London Developer Meetup returned to The Lightwell, and the running theme across the evening was less about individu...

Graham Carr | Jul 10, 2026

Optimizely’s Summer ’26 Roadmap: The CMS Is Starting to Look Less Like a Publishing Tool and More Like Marketing Infrastructure

Optimizely’s Summer ’26 Product Roadmap event was not just a list of product updates. At least, that is not the part I found most interesting. The...

Augusto Davalos | Jul 9, 2026

Optimizely Content JS SDK v2.1.0 — What's New and Why It Matters

  v2.1.0 of the Optimizely Content JS SDK and CLI landed on July 7, 2026. This is a substantial release bringing a wave of capabilities for...

Vipin Banka | Jul 8, 2026