Display due date in user timezone or company timezone

Question

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.

Answer 1

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.

Answer 2

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.