Handling Daylight Saving Time for scheduling purposes

Question

I am working with an API that generates time periods based on a configured set of parameters.

So for example, I can specify I want 12 one month periods starting Jan 1st at midnight, and therefore the API will generate 12 monthly periods

01 Jan 2016 00:00:00 – 31 Jan 2016 23:59:59
01 Feb 2016 00:00:00 – 28 Feb 2016 23:59:59
Through to
01 Dec 2016 00:00:00 – 31 Dec  2016 23:59:59

Now the API expects a start date param supplied for the sequence of periods to be an ISO formatted string in UTC. So I’m currently in the UK, therefore if I choose to start the monthly periods from Jan 1st 2016 this would be 2016-01-01T00:00:00Z and is what I supply to the API call I am making to say when the first instance of my monthly periods should begin.

So now if I view the start and end dates of the generated monthly periods via the API, I will see them come back as

2016-01-01T00:00:00Z - 2016-01-31T23:59:59Z
2016-02-01T00:00:00Z - 2016-02-28T23:59:59Z
Etc to
2016-12-01T00:00:00Z - 2016-12-31T23:59:59Z

Something struck me about these generated periods and that is I want them to begin at midnight for where I currently am, but a period that is affected by GMT Daylight Time, so say my April period will look like so in the generated period from the API

2016-04-01T00:00:00Z - 2016-04-30T23:59:59Z

Parsing the start date for the above into a date object for viewing in the client (on my machine) will show up as

Fri Apr 01 2016 01:00:00 GMT+0100 (GMT Daylight Time)

So it’s saying that period starts at 1am and not midnight. Now say if I wanted 12 months to be generated from 1st Jun when Daylight Savings is in effect.

My client side code currently will supply a start date to the API of 2016-05-31T23:00:00Z. This causes the API to generate start dates for each monthly period as being

2016-05-31T23:00:00Z - 2016-06-31T22:59:59Z (June Period)
2016-06-31T23:00:00Z - 2016-07-31T22:59:59Z (July)
Etc to
2017-04-30T23:00:00Z - 2017-05-31T22:59:59Z (May)

But now for a period that is not in GMT Daylight Time, so Jan for example it will show up as

2016-12-31T23:00:00Z - 2017-01-31T22:59:59Z

Meaning my client will see that start date as

Sat Dec 31 2016 23:00:00 GMT+0000 (GMT Standard Time)

So not Jan 1st at 00:00

Does this suggest that the API should know about the users timezone so the period generation logic in the API can factor this is when calculating the start and end dates?

Maybe I'm over thinking things here?!

Answer 1

The only real question I see here is:

Does this suggest that the API should know about the users timezone so the period generation logic in the API can factor this is when calculating the start and end dates?

In general, the answer is YES. Any time you are mapping calendar dates back to specific instants in time, then by definition you must involve time zones. That time zone can be that of the user's, or of some specific business location, or fixed to UTC, but they indeed part of the logic.

Consider that not every calendar date has a valid local "midnight" in every time zone. An example is 2015-10-18 in Sao Paulo Brazil, where the first moment of that day was 1:00 AM due to their spring-forward daylight saving time transition. There are many other examples of this around the world.

The only way to avoid the problem entirely is to not deal in specific times. If you are only working with whole dates, then your code can certainly compute the exact dates of each month without knowing anything about time zones. 2016-01-01 through 2016-01-31 has no awareness of time or time zone. It's only when you try to ask what the current date is, or if now is within that range, or if some other specific instant in time is within that range that you have to start thinking about time zones.