![]() ![]() #Universal database front ends software.You can ship both of those to the client, but it tends to make API's ugly. So, in order to do time zone conversion you need (A) the date and time at UTC (or something reducible to UTC like datetime+offset), and (B) a time zone identifier. A time zone is a calculation rule that when applied to UTC time gives you local time, but cannot be used in the other direction (because some local times occur twice or not at all, thanks to DST and other weirdness). I prefer ISO timestamps, because they include both offset and date and time in a readable way.Ī key thing to take into account is that date+time+offset does not tell you which time zone is involved. I prefer to do time zone conversions in the server, consistently from the same TZ database, so that there can be no odd differences because one part of the system has had a TZ database update and the other has not. This gets rid of a whole class of "off by a few minutes" errors. If you need the current time on the client, ask the server. With time and time zones experience has told me that you want to minimize the number of different places where the same thing is done. I think the answers to these questions should help you weigh the cost (development time, maintainability, complexity) versus the benefit. How often is the client expected to move around? Is the client on a transport truck, or is it a server in some data warehouse? have the server store the client's default timezone and then if the client reports that it has detected a timezone move, offer to the user that the time be displayed in both local and default zones. Is the time zone so important that your clients may need to display the time in multiple zones? e.g. How much does the time zone actually matter to your clients? Is it a delivery service where time is crucial, or is it a photo editing website where time is more disposable?Īs a corollary to the above, is it safe enough to auto-detect the client's time-zone, or is the time-zone so crucial that it should always be made an explicit option set by the user? You should attempt to answer the following questions: I think this can be framed not just as an ASP/React issue, but a general issue concerning server/client interaction. I guess letting JavaScript handle the time zone data may eliminate the worry created by user traveling to another time zone. For example, user may tell me that he/she is in US Eastern Time Zone but then travel to California i.e. The advantage of this approach is that JavaScript captures the user's time zone in real time and can be more precise. Second option is to send UTC values to the React front-end as well as the mobile apps and let JavaScript handle the work of displaying date/time values based on user's time zone that it captures in runtime.This is an advantage especially for older smart phones with limited system resources. ![]() The advantage of this approach is that the front-end doesn't have to do any work. I can store user's time zone in the database and send all date/time values already converted to user's time zone - based on the saved time zone data.I have two options in handling time zone conversions and wanted to get some opinions on which is a better approach. It also has a mobile app built in React Native. I have a web app with an ASP.NET API back-end and React front-end. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |