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 · Accepted solution]

Hello @Scott Eaglesham ,

It depends a bit on which time zone you mean when you say "local time". A fixed time zone (yours, GMT), or the local time zone of the user who triggers the flow?

In the first case you can use the following:

var starttimestring = '2025-04-02 19:00:00';
var starttime = new GlideDateTime(starttimestring);
starttime.setTimeZone('Europe/London');
starttime.subtract(starttime.getTZOffset());
grChangeRequest.start_date = starttime;

In the second case remove the "setTimeZone" part.

Regards,

Robert

[Ankur Bawiskar]

@Robert H 

Do you know how setSchedule() works when DST comes into picture.

I am getting 1 hour less i.e. the schedule is 8 to 5 so it should give me 40 hours but this returns 39

 var weekStartDate = new GlideDateTime(timeSheetStartDate); //week start date
	gs.info('week start date' + weekStartDate);
    var weekEndDate = new GlideDateTime(timeSheetStartDate);
    weekEndDate.addDaysUTC(6); //week end date
	gs.info(weekEndDate);
    var durationCalculator = new DurationCalculator();
    durationCalculator.setSchedule(userSchedule);

If I give UTC in that line as 2nd parameter to setSchedule() then it works fine

setSchedule(userSchedule);

We suspect that the problem lies with the setSchedule() method used in the calculations when Daylight comes into picture, as it is producing inconsistent results.

[Shivalika]

Hello @Scott Eaglesham 

It's because the system time zone is set to US TIME ZONE. We also faced this. And this will happen because of DayLight Savings. One hour was gone, so now everything moved 1 hr ahead. 

You need to change the system time zone to reflect this, but why is it needed ? That's how it works everywhere, is it sort of business requirement? 

Kindly mark my answer as helpful and accept solution if it helped you in anyway. This will help me be recognized for the efforts and also move this questions from unsolved to solved bucket. 

Regards,

Shivalika 

My LinkedIn - https://www.linkedin.com/in/shivalika-gupta-540346194

My youtube - https://youtube.com/playlist?list=PLsHuNzTdkE5Cn4PyS7HdV0Vg8JsfdgQlA&si=0WynLcOwNeEISQCY

[Scott Eaglesham]

Thanks for your responses. I managed to resolve by using isDST() to check if date/time uses daylight savings offset and, if so, setting to 1 hour earlier.