Vulnerability in EPiServer.Forms

Try our conversational search powered by Generative AI!

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


], 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
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 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
Stop Managing Humans in Your CMS

Too many times, a content management system becomes a people management system. Meaning, an organization uses the CMS to manage all the information...

Deane Barker | Nov 30, 2023

A day in the life of an Optimizely Developer - Optimizely CMS 12: The advantages and considerations when exploring an upgrade

GRAHAM CARR - LEAD .NET DEVELOPER, 28 Nov 2023 In 2022, Optimizely released CMS 12 as part of its ongoing evolution of the platform to help provide...

Graham Carr | Nov 28, 2023

A day in the life of an Optimizely Developer - OptiUKNorth Meetup January 2024

It's time for another UK North Optimizely meet up! After the success of the last one, Ibrar Hussain (26) and Paul Gruffydd (Kin + Carta) will be...

Graham Carr | Nov 28, 2023

Publish content to Optimizely CMS using a custom GPT from OpenAI 🤖

Do you find the traditional editor interface complicated and cluttered? Would you like an editorial AI assistant you can chat with? You can!

Tomas Hensrud Gulla | Nov 28, 2023 | Syndicated blog