Script returning wrong time after daylight savings time change

[Scott Eaglesham]

I am in GMT time zone and moved forward 1 hour to daylight savings time yesterday, so instance time is now UTC+1.

Using the following...

var starttime = new GlideDateTime(starttimestring)

gs.log('starttime: ' + starttime)

return starttime

...(where starttimestring=2025-04-02 19:00:00) in Planned Start Date field in Create Change Request Record in a flow, set the field correctly to 02/04/2025 19:00:00 before daylight savings time change, but now sets the field to 02/04/2025 20:00:00. System log shows 'starttime: 2025-04-02 19:00:00'.

On reading some other posts on similar issues, I tried the following...

var starttime = new GlideDateTime(starttimestring)

gs.log('starttime: ' + starttime)

var starttime1 = new GlideDateTime(starttime.getDisplayValueInternal())

gs.log('starttime1: ' + starttime1)

return starttime1

...which results in system log entries 'starttime: 2025-04-02 19:00:00', and 'starttime1: 2025-04-02 20:00:00' and sets the field to 02/04/2025 21:00:00.

Can anyone advise a way to ensure the field is always set to correct local time?

[Robert H]

Hello @Scott Eaglesham ,

Working with date and time in ServiceNow can be a headache, especially when different time zones get involved. 

Maybe the following example helps:

function dateInfo(date) {
    gs.info(gs.getMessage('internal: {0}, display: {1}, DST?: {2}, TZ offset: {3}',
        [date, date.getDisplayValue(), date.isDST(), date.getTZOffset()]));
}

var date = new GlideDateTime('2025-04-02 19:00:00');

gs.info('Time zone of current user: ' + gs.getSession().getTimeZoneName());
dateInfo(date);

var forcedTimeZone = 'Europe/London';
gs.info('Now we are forcing the date to be interpreted as per time zone ' + forcedTimeZone);
date.setTimeZone(forcedTimeZone);
dateInfo(date);

Output when I run this script (in Germany):

Time zone of current user: Europe/Berlin
internal: 2025-04-02 19:00:00, display: 2025-04-02 21:00:00, DST?: true, TZ offset: 7200000
Now we are forcing the date to be interpreted as per time zone Europe/London
internal: 2025-04-02 19:00:00, display: 2025-04-02 20:00:00, DST?: true, TZ offset: 3600000

And now I change my time zone to Hongkong:

Time zone of current user: Hongkong
internal: 2025-04-02 19:00:00, display: 2025-04-03 03:00:00, DST?: false, TZ offset: 28800000
Now we are forcing the date to be interpreted as per time zone Europe/London
internal: 2025-04-02 19:00:00, display: 2025-04-02 20:00:00, DST?: true, TZ offset: 3600000

Note that, no matter what the script is doing and who is running it, the internal value of the "date" object never changes. It will always be the date that we passed as a string when creating the object, which ServiceNow expects to be in UTC. And this is also the value that will be stored in the database if, for example, we were to set the value of a Change Request's Planned start to "date". This can be verified by looking at the XML of the record: you'll see '2025-04-02 19:00:00' there. So again, dates are always handled in UTC internally.

When someone looks at a date/time field in the UI, that internal UTC date will be interpreted as per the time zone that the user has set in their preferences. Same for GlideDateTime methods like "isDST" or "getDisplayValue": they take that internal UTC value and interpret it as per current user's time zone, or as per the time zone that we are enforcing via "setTimeZone" (but again, this does not change the internal value).

That's the fact that's used in the solution I proposed in my first reply: if you want to ensure that a user in Great Britain sees '2025-04-02 19:00:00' when looking at that field in the UI, you'll have to add or subtract time from the internal value so that you end up with the UTC date that corresponds to 2025-04-02 19:00:00 in Great Britain (by the way, I have updated my original solution because I learned today that the time zone name for Great Britain is actually 'Europe/London'; GMT is the time observed during winter and BST is the time observed during summer).

So regarding the two questions that you added today:

1. "So if, for example, a Hong Kong based user ran the script using isDST(), which, as you say, always returns false for them, the field would be set incorrectly to UTC time instead of Hong Kong time?"

If your script subtracts one hour if isDST() is true, then this subtraction would not happen when run by a Hong Kong user, and the field would (internally) be set to '2025-04-02 19:00:00' UTC, and what users see in the UI when looking at it depends on the time zone set in their preferences.

If I (in Germany, where we currently observe daylight saving time) ran the script instead then one hour would be subtracted and the internal value would be set to '2025-04-02 18:00:00' UTC.

2. "Also, would removing the "setTimeZone" part in your script work for all timezones, indluding GMT?"

In that case, if a Hong Kong user ran the script, the internal value would be set to '2025-04-02 11:00:00' UTC, because that is the UTC time that corresponds to 2025-04-02 19:00:00 Hong Kong time. If a London based user ran the script the internal value would be set to '2025-04-02 18:00:00' UTC because that corresponds to 19:00:00 London time. Again, what other users see in the UI depends on their own time zone.

Hope that helps.

Regards,

Robert

[Scott Eaglesham]

Thanks for the comprehensive reply @Robert H. Much appreciated and very helpful 👍