REST API standard/best practice for specifing daylight saving time

user_4353546 0
Viewed 302

I have a set of REST APIs. There is a case where I would like to get data based on given time like below :

2020-02-06T00:00+09:30

If I'm in australia's time (Australia/Adelaide), I would send the above date in the API to get the respective data on feb 6th. +9.30 is the offset of Australian central standard time.

But, there is a case where the specified time falls in daylight saving period in that timezone. In the above mentioned timezone, daylight saving is followed from april to october with offset of (+10.30). So, if I had to get data of september, should client provide the necessary offset based on the date (with +9.30 for february's date and +10.30 for september's date)?

or should client send dates with it's current timezone's offset (oblivious to daylight) and should it be server's responsibility to identify dates that fall in daylight saving and normalize that date by one hour before processing? Which would be the proper way to handle such a case in REST? kindly assist.

rest
1 Answers

Broadly, I would say that these are good recommendations:

  • Don't use offsets, use Olson IDs. So the time you return should include Australia/Adelaide, not +9.30. Any date library worth it's weight can understand Australia/Adelaide.
  • If you're working with things that happened in the past, it's generally easier to to just use UTC. Your server can use UTC for all these, and just let the client handle translation to a local timezone before viewing. But this tends to be best to handle in the view/presentation layer of your app, not the data model. One example why this is helpful, is because "1:30am" happens twice the night when we transition to winter time.
  • For anything that is 'scheduled' in the future, it's typically best use 'local time' + a timezone identifier. For example, if you want something at 2PM every day of the year, you will need to know what timezone it's in to adjust for DST changes. DST rules change every year for some countries in the world, so this makes your system future proof.

So if you are booking a meeting with someone next year, at a specific (local) time. There's no 100% guarantee yet which UTC time that will be, because local time rules might cause a shift. Most countries' timezone rules are pretty stable, but certainly not all of them.

user_809110
Related