Say there is a group of users in a company (which is my SaaS model). Company has a timezone on which it operates. Also, users have their own timezone. When creating an task/event, we get the due date in the form as an input.

On submitting the form, should the event's due date be considered in reference with the company timezone or the user timezone?

Also there are instances where the event along with its details be listed. In that list, should the date be converted to user timezone for easy communication or should i globally maintain the company timezone as reference.

2 Answers 2


The principle here should probably be to display the date/time so that it does not need to be mentally converted to the reader's local time. This is to minimise cognitive effort and prevent mistakes. This may of course depend on the contexts in which the date/time is read.

So in this case, the user inputs an event using their time zone. The display of the date/time then defaults to that of the person who is reading it.

If for some reason the reader would modify their behaviour if they knew that the input time zone had been different from their (output) time zone (for example, they perhaps should not move a meeting into a time when some participants would be asleep) then it would be good for them to know the input time zone as well.

Perhaps in your case you could indicate "office time" in those situations, so for example an event would display "April 12th 14:00 (15:00 Paris time)" where Paris is the city in which the event input occurred if it was different from the reader's location.

Note that for this to work, the system has to know what time zone any given reader of a date/time is in.

  • thanks for the suggestion. I will consider this while designing my SaaS product. Nov 10, 2022 at 13:07

Allow the user to pick a date/time in a formatting that's familiar to them. Usually you can rely on the browser presenting a native date/time input control in their locale, as this follows the user's browser or system settings. If you use a library, then make sure it's capable of localized inputs.

In the backend I would strongly suggest that you use UTC everywhere. This means you'll have to know the user's timezone when you convert the form value back to UTC. You can either make this a user setting in their account configuration which you store in the backend, or you can convert the timezone client side (Intl.DateTimeFormat().resolvedOptions().timeZone will get you the timezone in JS).

To present date-times from the db that are local to the user, you obviously convert back from UTC to their timezone.

  • Why would a user pick anything other than their current time zone? This would seem to be a rather confusing option to have which violates the pareto principle of not annoying/confusing the majority for the sake of a (tiny) minority. Nov 10, 2022 at 18:46
  • @TommyPeanuts, they wouldn't. I'm not sure which part of my answer confused you. But my suggestion was to allow the user to select their own timezone. They ought not be bothered dealing with timezones for as much as possible. Ideally, if a user timezone preference is afforded, it would be intelligently preselected. Nov 11, 2022 at 8:57
  • Whoever downvoted, please explain why you think this answer is wrong. Nov 12, 2022 at 14:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.