Why would GlideDateTime->getLocalDate() return inconsistent results?

[Greg92]

Hi,

I am querying pm_project table to get schedule_end_date. For some reason getLocalDate swaps days and month for one of them. Here is the script

var prj = new GlideRecord("pm_project");
prj.addQuery('number', 'PRJ1');
prj.query();
prj.next();
var endDate = new GlideDateTime(prj.getDisplayValue('schedule_end_date'));

gs.info("Project: PRJ1")
gs.info("Stored Date: " + prj.getDisplayValue('schedule_end_date'));
gs.info("Local Date: " + endDate.getLocalDate().toString());


prj = new GlideRecord("pm_project");
prj.addQuery('number', 'PRJ2');
prj.query();
prj.next();
var endDate = new GlideDateTime(prj.getDisplayValue('schedule_end_date'));

gs.info(" ");
gs.info("Project: PRJ2");
gs.info("Stored Date: " + prj.getDisplayValue('schedule_end_date'));
gs.info("Local Date: " + endDate.getLocalDate().toString());

Here is the result:

*** Script: Project: PRJ1
*** Script: Stored Date: 30/06/2021 17:00:00
*** Script: Local Date: 2021-06-30
*** Script:  
*** Script: Project: PRJ2
*** Script: Stored Date: 03/05/2021 09:00:00
*** Script: Local Date: 2021-03-05

As you can see the second is not correct 

Can you please help?

[Brad Bowman]

Hi Greg,

I don't know if any of this matters in this case - and it's hard to replicate without knowing your user vs system Time zone and Date formats, but there are some practices in your script that should be avoided - bad habits even for test scripts.  Set your second GlideRecord to a new variable instead of reusing prj.  Don't declare duplicate variables like endDate - you're just inviting trouble.  After a .query(), wrap your actions in a  if(prj.next) block so that they're only carried out if the query returns a record.  When instantiating a new GlideDateTime, just use the field, like prj.schedule_end_date so that the basis for the variable is the system date and time, not a value that's starting off converted for your time zone.  Just so you're clear, your definition of 'Stored Date' is not showing the actual value stored in this field, it's that value converted to your time zone and date/time formats which could show a date difference vs. Local Date if the time zone offset is enough.

I don't think any of this is enough to explain the switch you're seeing.  I'd be interested to see if you can make this happen on dates that aren't valid in the mm/dd/yyy format like 13/5/2021, and confirm what the actual stored value is along with all of the above.