Leaderboard

You should only be using one timezone in all your code and storage. UTC works well but pick whatever you want and use it. By using a single timezone and datetime types then most of this problem goes away. Regardless of what the users local timezone is, you store the date and time in your chosen timezone. Then whenever you want to compare to it you also compare the current time in your chosen timezone to that stored date and time. If you want users to view dates and times in their timezone then convert them from your chosen timezone to their timezone just prior to display. If your using generated times then things are pretty easy in general. If your taking user-submitted dates and times, then things can potentially get a little more complex. If you want users to deal with things according to their local time you'll need to convert their input from their timezone to yours before doing and processing. This is just something you need to decide as one of your business rules. You also need to decide if whatever date you pick is inclusive or exclusive. If I were to subscribe on 2020-04-17 @ 5:20, for one year then does my subscription run 2020-04-17 @ 5:20 -> 2021-04-17 @ 5:20? 2020-04-17 @ 0:00 -> 2021-04-17 0:00? 2020-04-17 @ 0:00 -> 2021-04-17 @ 23:59:59? Up to you to decide. If it were me, I'd probably go for for the last option as I think it's the most intuitive and what people would expect. People are not going to remember the exact minute they signed up, and on the scale of a year I wouldn't nit-pick a few hours.