Correct format to receive datatime data from consumer

Question

I am working on a service in a sprint boot microservice application. The consumer for my service can be another service, as well as a UI component.

The are 5 entities in my service, each entity having it's own set of CRUD APIs. Four of these entities have two datetime fields - event_start_date_time and event_end_date_time, where I store date and time without timezone (as it is assumed that the consumer will send datetime in UTC). For ex:

2020-01-01T00:00:00

In one of the entities though, only date is needed - start_date and end_date. However, for the sake of consistency, like in other entities, I have been instructed to use datetime here as well. So if the user wants to book something from 2020-01-01 to 2020-01-05, it should be represented like this -

2020-01-01T00:00:00
2020-01-05T23:59:59

Now my question is, should I expect from the consumer to send the data in above format (appending 00:00:00 and 23:59:59 to the dates)? Or should my service handle this?

If the consumer does this, then he can add some other time as well, like instead of 00:00:00 and 23:59:59, might put 00:00:05 and 14:00:00. My service can ignore consumer's time input and add correct one itself, but then it would be like discrediting the actual data that consumer has sent.

If my service is to handle it, then the API will only have date and I will be appending time part to it. But this way, it will not be consistent with the other 4 entities.

What can be the best way to do it?

Any other way to do is appreciated as well, just remember that it has to be date and time both.

Thanks.

Answer 1

If you have been instructed to use datetime in the API although the service deals in dates only, you should request clear guidance from the authors of your requirements about how to handle non-canonical inputs such as timestamps which are not at start/end of the day or just date values which you might receive from clients who assume that since only dates are required the API spec may be wrong (yes that happens.)

You may guess how to best do it, we also may guess but may be more likely to be wrong since we know less about the project. If specifications are open to guessing, it's possible that your interpretation differs from that of other readers of the specification, resulting in incompatible implementations and perceived bugs.

Getting unambiguous specs early is the best way to prevent this kind of problems.