is cmn_schedule_span table fields start_date_time and end date_time got any changes due upgrades

[surya76]

we SNOW have integrated with third party.

my third party with give the schedule dates in the payloads

Example payload that we receive from third party:

{

"Name":"schedule_on_every_friday",

"type":"weekly",

"startdate":"28/03/2024 02:00:00",   // this is the format we receive 

"Enddate":"28/03/2024  04:00:00";  // this is the format we receive 

}

This is the payload format they were giving us the dates since three years

and we in our script include just store the value as same as they give  like

var gr = new GlideRecord('cmn_schedule_span');

gr.query();

if(gr.next()){

gr.start_date_time = payload.startdate;

gr.end_date_time = payload.Enddate;

}

with this we snow will be able to populate date and time exactly what we recieve.

but suddenly now after our instance upgrade to vancouver it is populate the dates correctly but not the time it just populates the time as 00:00:00 for both start and the end time of schedules 

but if i try changing the dates to below format , it working perfectly

{

"Name":"schedule_on_every_friday",

"type":"weekly",

"startdate":'2024-03-28 02:00:00',

"Enddate":'2024-03-28 04:00:00';

}

but i need to justify why this change is occured to my third party as well, so i need to know why this is happening?

[Mark Manders]

First: is it really necessary to ask the same question three times within an hour? It would make it much easier for later reference to just be patient and wait for someone to answer it, instead of repeating yourself. At least delete the previous ones, when you create a new one.

https://www.servicenow.com/community/virtual-agent-forum/is-cmn-schedule-span-table-fields-start-dat...

https://www.servicenow.com/community/itsm-forum/is-cmn-schedule-span-table-fields-start-date-time-an...

https://www.servicenow.com/community/developer-forum/is-cmn-schedule-span-table-fields-start-date-ti...

Second: why ask questions about SNOW on the ServiceNow community? SNOW is a completely different software company.

Third (assuming this is related to ServiceNow and not SNOW): can you add logging to the integration to see what is really in the payload and what is really being set? 

The behavior you're experiencing, where the time part of your datetime fields defaults to 00:00:00 after your ServiceNow instance upgrade to the Vancouver version, is likely due to changes in how ServiceNow parses datetime strings in this newer version. It's a common scenario after upgrades for certain functionalities to behave differently due to platform enhancements or changes in how ServiceNow handles data.

In earlier versions, ServiceNow may have been more lenient in accepting datetime formats, but with the upgrade, it seems the platform expects a more standardized datetime format, specifically the ISO 8601 format (YYYY-MM-DD HH:MM:SS), which is widely used and supported across many systems for its unambiguity.

The problem with the datetime format "28/03/2024 02:00:00" is that it's more susceptible to locale and interpretation differences. For instance, the DD/MM/YYYY format is common in many parts of the world, but not in others where MM/DD/YYYY is standard. This ambiguity can lead to issues in software that expects a specific format.

In the Vancouver version, ServiceNow might have enforced stricter validation on datetime fields to ensure consistency and reduce issues related to datetime ambiguity. This enforcement would explain why the system no longer recognizes your original format and defaults the time to 00:00:00, effectively stripping out the time component because it cannot reliably parse it.

For your third party, you might explain that the change in behavior is due to enhanced datetime handling in the newer version of ServiceNow, aimed at improving data consistency and reliability across the platform. It's a common practice in software upgrades to align with more standardized formats for data interchange, like ISO 8601 for datetimes, to reduce errors and improve interoperability with other systems.

To address this, you could request that they adapt their payload to use the more standardized ISO 8601 datetime format. This change not only ensures compatibility with your updated ServiceNow instance but also aligns with best practices for datetime representations in APIs and data exchanges, making their payload more universally acceptable.