Project level Forecast Outputs Missing swDate for some segments

Bugs
1

When querying the https://api.combocurve.com/v1/projects/:projectId/forecasts/:forecastId/outputs endpoint, we noticed today that the swDate is not in the segment for some records anymore. Was it intentional to remove it? We are not using the CC SDK but are using raw HTTP GETs for this endpoint.

I did notice that some swDates have a default value of ‘1900-01-01’. In the case where swDate is missing, is it acceptable to set the value to ‘1900-01-01’ on our end as a workaround?

Here is an example of a segment containing a swDate:

image
image432×324 22.1 KB

Here is an example of a segment where the swDate is missing:

image
image390×317 20.2 KB

2

We’re already working with our main ComboCurve API & Forecast dev teams to confirm why some swDate fields are dropping out.
• We’ll update this thread as soon as we have root-cause details and a timetable for the fix.

2 Likes
3

For what it’s worth, it also looks like the date serialization format was recently changed to remove the time component for some dates (possibly swDate, startDate, endDate). For example, I think swDate used to include both the date and time at UTC like 2025-06-17T12:43:06.120Z but now it only includes the date like 2025-06-17.

It’s probably not a big deal, but I just wanted to mention it here because the change could break some client libraries if they assume the time will be included. Some ISO 8601/RFC 3339 parsers expect the time to be included depending on the type they’re trying to parse (date vs. date-time).

4

Thanks for posting here.

As Danny mentioned, we met and reviewed the current behavior of the endpoint. Originally, we had put a hard limit on any dates beyond the year 2999, this affected startDate, endDate, and swDate. After syncing with the Forecast team, we decided to remove that restriction for swDate, and increase the cutoff for startDate and endDate to 3000.

These limits are temporary while we work on unifying date handling across the forecast module (both UI and API). If they change again, we’ll make sure to let you know.

As part of the upcoming release, you’ll get swDate returned regardless of its value. The missing timestamp is also tied to the same logic. Apologies for any confusion this might’ve caused.

5

Thanks Angel. Do you have a date for the upcoming release so we’ll know when to re-enable a process on our end which consumes the swDate?

6

Hey Damon,

The next release is expected sometime next week, but we went ahead and pushed a hotfix so you can re-enable your process now and double-check that everything’s working on your end.

You should start receiving any switchDate values from the endpoint. I want to remind you that we’re still working around some limits, so if anything changes there, we’ll post it in our release notes, here in the forum, or via email.

Let us know if everything looks good or if you run into anything.

1 Like
7

@Angel_Torres can you confirm if you are going to keep the new date serialization format change that @josh highlighted? My workflows were impacted by this switch, so I just need confirmation which direction will be taken.

8

Hi Jose,

Yes, we’re keeping the change. We’re currently updating the docs to reflect the new format.

Going forward, we’ll make sure to give a heads-up through any of the aforementioned channels if anything else changes.

1 Like
9

Sounds good and a notification system would be great to minimize the amount of break-fix/reactionary work on our end.