If I have two servers (application and database) with different time zones, which one is better to use as a base?

Asked

Viewed 166 times

4

I am working with the Mysql server of a hosting, I can not change the time zone of the same, I mean it uses the "Mountain Standard time (MST)", on the other hand, I am using the ASP.NET server and I can set the time zone for the time of "Horario de Brasilia (BRST)", the difference is that the MST has -5 hours and whenever I compare something using the DateTime.Now on ASP.NET I have problems.

Which is the most usual to work by default?

  • Maybe this article from Microsoft can help you work around the problem https://docs.microsoft.com/pt-br/dotnet/standard/datetime/converting-between-time-zones

  • Set a pattern and always use it regardless of what the server uses.

  • It seems to me that you have a design problem, not just implementation, you routines that take the time at the bank instead of going through the application layer? that’s it?

  • I have the following: I need to compare time intervals to allow or not allow a user to download. When I use the NOW() from MYSQL, it returns to me say 00:00:00, when using the DateTime.Now from C# , I get 5:00:00.

  • I would like to know what standard to adopt

  • Universal UTC time, is used as the basis for all times

  • Theoretically the server must answer its local time, if your mysql is an internal part, then this is not very important for the user, for internal issues the output is convert to UTC (universal time) and compare the times, but as you already know beforehand that are 5 hours difference just add (or subtract if applicable) 5 hours before comparing... Some agents check the timing of each other, so it is important to provide the correct time to the user, in a more generic case...

Show 2 more comments

1 answer

4


Schedules should always be stored and manipulated like UTC, so no problem will occur (or almost, it is not so simple, but for most scenarios is ok). You only handle local time at data input and output, always making the input convert to UTC and the UTC be converted to local time desired in that context.

No matter what your infrastructure is, this is the only correct way, unless you need a fixed time marker, where the time itself (a point on the timeline) doesn’t matter, but what you were showing on a specific clock or is an abstract time indicator, what perhaps should even be just a text.

Wrong forms should only be used when there is a legacy of data that requires this and cannot be conformed to a new standard (it has multiple time places, but it is not known which is the one for each hour, or code it handles incorrectly. Both will be nightmares.

If applicable, in data doesn’t have much to do without assuming wrong things, if code the solution depends on each problem.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.