We are in the process of converting to V3 APIs to get around the unfinishable requests for get Customer bulk.

As part of this effort we noticed that the closed sales and service deltas have different default behavior for the date ranges.  

Is this intentional?  If so, why?  If startDate is not passed to sales we get the full delta range.  If start date is not passed to service we only get the current day? not the max delta range?  Why are you making this so complicated?  If you pass a date to sales it requires a time component and service does not? sales has no time zone specification yet service does?  You are causing us a lot of unneeded headaches buy having these inconsistencies and potential for gaps in our data.  

So do these APIs actually behave differently or is the documentation wrong? Or is it like V2 where the service closed delta behaved differently from the documentation (see case #02009683). 

Can we trust not sending a start date to sales delta and actually get 48hrs of changes?

Here is a service example that hopefully resonates. 

If I call get delta at 3pm pacific on 8/28 and calculate a start date 48hrs prior then passing the UTC date 2025-08-26 I get a 400 error, if I pass 2025-08-27 it works, the problem of course is 8/27 UTC is 5pm pacific from the previous day, am I going to get service orders that closed prior to 5pm?  Your api summary documentation says the last 48hrs but depending on when I call and how the api interprets the date (UTC or undocumented local like v2) I could be getting less then 48hrs depending on the time of day I call and where the dealership is located.  If you were instead to accept a time component or have a reasonable start default that guaranteed I would always get 48hrs we could have some certainty that our data does not have gaps.

Please provide some clarity and consistency