Do not use gs.nowDateTime() or GlideDateTime.getDisplayValue() in a GlideDateTime constructorIssue Do not use gs.nowDateTime() or GlideDateTime.getDisplayValue() in a GlideDateTime constructor. The GlideDateTime constructor has a number of options: No-argument: Initializes to the current date/timeGlideDateTime object: Initializes to the same date/time as the argumentString: In the format YYYY-MM-DD HH:MI:SS and is treated as if it is a UTC date/time. Passing in a string value which is not UTC will lead to a shift in the time, leading to unexpected behaviour. CauseTo create a GlideDateTime object with the current date and time, do not provide a parameter. Simply call the constructor of the GlideDateTime class and the value is initialized to the current date and time. // Do thisvar dgt = new GlideDateTime(); Do not use gs.nowDateTime() to set a GlideDateTime object. The nowDateTime() method returns the date time in local format and the local time zone. The GlideDateTime object uses the date time in the internal format and UTC time zone. //Not thisvar gdt = new GlideDateTime(gs.nowDateTime()); Similarly if the code is effectively doing the following by using the display date/time value and using it where it should be UTC: var gdt = new GlideDateTime();var gdt2 = new GlideDateTime(gdt.getDisplayValue()); then the second GlideDateTime object's internal value will shift by an amount equivalent to the TZ offset between the session's time zone and UTC. Here is a full example: var gdt = new GlideDateTime();gs.info('1. UTC: ' + gdt.getValue());gs.info('2. Local/Dispay: ' + gdt.getDisplayValue()); // Local TZ for this example is America/Los_Angelesgs.info(' ');gs.info('3. nowDateTime: ' + gs.nowDateTime());gs.info(' ');var gdt2 = new GlideDateTime(gs.nowDateTime()); // BAD!gs.info('4. UTC: ' + gdt2);gs.info('5. Local/Display: ' + gdt2.getDisplayValue()); which outputs: *** Script: 1. UTC: 2022-01-18 16:48:13*** Script: 2. Local/Display: 2022-01-18 08:48:13*** Script: *** Script: 3. nowDateTime: 2022-01-18 08:48:13*** Script: *** Script: 4. UTC: 2022-01-18 08:48:13*** Script: 5. Local/Display: 2022-01-18 00:48:13 In the above output, the first GlideDateTime object, which is intialized to the current date/time since no value was passed to its constructor, (2) and (3) both display the local date/time formatted according to the glide.sys.date_format and glide.sys.time_format, and (1) shows the GlideDateTime's internal UTC value. The second GlideDateTime object was passed the local date/time value, which is already offset -8 hours from UTC as the instance is using America/Los_Angeles as its default timezone and this has not been changed in the session where the script has been run. As the GlideDateTime(string) constructor only expects a date/time value in UTC, then the American/Los_Angeles date/time value is shifted by -8 hours for both the internal value (4) and display value (5). Additional problems could occur if you are using a non-standard date/time format. The GlideDateTime(string) constructor will, if it is unable to convert the string to a valid date/time using the format yyyy-MM-dd HH:mm:ss, will try a number of 'emergency' formats and if the string argument can be successfully parsed with one of those formats then what date/time is set may not be what is expected. Enabling Debug Date/Time will show if this is occurring and common problems can occur when an instance is configured to use a date format like dd/MM/yyyy and is given a date in the format MM/dd/yyyy. For example the 3rd January 2021 as 03/12/2021 using dd/MM/yyyy would match MM/dd/yyyy first and the date would be 12th March 2021. Note: The gs.nowDateTime() method is not available in scoped applications. ResolutionEnsure that display date/time values are not used in a context where UTC is expected. This can be made clearer in code by using the getValue()/setValue() and getDisplayValue()/setDisplayValue() methods consistently throughout the code.