Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/11/2020 in all areas

  1. 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.
    1 point
This leaderboard is set to New York/GMT-04:00
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.