There could be many ways of saving DateTime in an App. The simplest way is storing it as it is typed in by users if the website’s users are within a single country. If a website is serviced globally, confusion starts.
Normally users might assume the date-time is local time. For example, if a user in Sydney(GMT +10) stored date 2020-06-16 00:00 and another user from Perth(GMT +8) retrieve the data it will be shown as 2020-06-15 22:00 ending the date has changed to a different day.
What if a user is in Perth and the webserver is in Sydney. For example, the user in Perth type in 2020-06-16 00:00 and it will be stored as 2020-06-15 22:00 in DB, if the DateTime is assumed as local time in backend code in Sydney.
To mitigate this problem, a known best practice is always saving DateTime in DB as UTC and convert it to Local time when showing to users.
In practice, the front-end should send the datetimeoffset of the current user back to the backend server. Then, the backend server can save it as UTC in DB or save it as DateTimeOffSet type.
However, a user in Sydney saves a date, 2020-06-16 00:00 local time. If another user from LA will see it as 2020-06-15 06:00. Will the user from LA understand the date-time is what actually happened on 16th in Sydney time. So, it might be needed to show the timezone of the date on the screen next to the DateTime.
In a different scenario, if the datetime needs to be a specific datetime globally regardless of timezone. We might be able to store it as UTC and show it as UTC to users too. For example, a datetime is about company announcements in the Sydney stock market exchange, it will be always in Sydney time to all users globally. In this case, coding can be unexpectedly confusing due to the fact that how web browsers and web servers communicate with datetime.
A web browser sends datetime to web server without datetimeoffset. The web server will take this datetime as an unspecified time zone. This is why the front-end need to send datetimeoffset separately to the webserver.
When the webserver reads datetime from DB without offset, it will be parsed as datetime unspecified offset and will be sent back to the front-end as local time (implicitly assumed as local time). The web browser smartly converts this datetime to users local time again. If know what’s going on between web browser and web server, it might be possible to deal with it, but with knowing it, this behavior of datetime conversion can be very confusing.
One example of how to deal with the datetime in UTC on both client and serverr will be this.
In conclusion, 1. Always save datetime in UTC in DB. 2. Send end-users datetimeoffset to a backend, if it needs to view it in local time.
Unix Timestamp Online Conversion Tool https://www.epochconverter.com/