Tell me, what reefs can stumble, if you store the date not in the UTC time zone, but in some other (local) one? Wherever I read information on this subject, it is recommended to store it in UTC without giving reasons. I use MySQL.

Such a "perversion" is needed for several reasons: 1. In order not to rewrite the code of an already existing application (in many months NOW () is used). 2. It is more convenient to view the date in the database through the same PhpMyAdmin in the local time zone.

As far as I can imagine, the only "cant", perhaps, is double conversion: TimezoneDB -> TimezoneUTС -> TimezoneUser, instead of TimezoneUTС -> TimezoneUser, if the time was stored in UTC, although perhaps it will work out one: TimezoneDB - > TimezoneUser?

    1 answer 1

    Formally, the absence of UTC (storage in the DATETIME type, and not in TIMESTAMP) can lead to different results compared to the presence of UTC in just a couple of cases.

    The first is if a node appears that “lives” in another zone (and it doesn't matter if it is a client or say a slave server), including in the case when a backup is deployed on such a node. However, the same problems are possible if the time zone is incorrectly configured on such a node — on the contrary, the presence of UTC will lead to problems.

    The second is the problems associated with the transition to summer time and back, if it exists in the current time zone. Especially when the adjustment is performed "to the minus" - "records from the future" may appear in the database, and sorting the events by time (as well as the results of calculating the time difference between the records) will not correspond to the actual.