Search code examples
datetimeformatiso8601

Is there a convention about passing times in UTC vs local time with an offset?

I'm in the UK, where my local time zone is GMT, which has a zero offset - the same as UTC. however, we're currently in summer time (BST), meaning we're +1 hour.

So for example, the local time now in BST is "2020-07-22 10:10:40", and in UTC it's "2020-07-22 09:10:40".

If i was passing a time to an API, using the ISO 8601 format, I have a choice of

  1. converting it to UTC, and putting a Z on the end to signify that it's UTC, eg:

"2020-07-22T09:10:40Z"

  1. showing my local time, and adding the time zone offset on the end, like so:

"2020-07-22T10:10:40:00+01:00"

Is one of these "better" than the other? I guess maybe it depends on the API, but I wondered if one was considered better practise than the other, or if there were some specific problems of using one or the other.

thanks

Solution

  • If the API accepts both and doesn’t need the offset information, there is no rule or practice. So here’s a suggestion: Do what is more convenient for debugging and for support. So if you expect support personnel to be in Britain too, send British time. If you expect overseas personnel to have to read the data transmitted occasionally, send UTC.

    After all ISO 8601 was designed to be human readable and machine readable. Your data are equally machine readable no matter which offset you opt for. Human readability is subjective. So let yourself guide by the humans that may actually be reading your data,

    It’s true that there is a general guideline recommending UTC for time interchange across time zones. IMHO this guideline says that the designers of your API might have restricted incoming messages to UTC only. If they didn’t, I’d say you‘re free to do what is best for you. This also said not knowing whether your data is going out to any other time zone.

    I was recently in a similar situation. I first did pretty thorough tests to verify that the receiver of my data didn’t care about offset. Then I opted for sending the time with my local offset. Both sender and receiver would currently be in the same time zone (with a remote possibility that the system might later be deployed in another time zone too), and I needed to log all exchanged messages, so for anyone reading the log I found it convenient that the local time was there.