但我认为我的做法有所不同。
我想获得用户使用它的时区登录平台的平均时间。这将作为某种统计信息提供给用户，例如：
本周每天平均登录X次
由于时区可能意味着登录在一周之内或之间的差异，我已经使用以下解决方案来解决问题，并考虑其优缺点。
我的自然方法是使用纪元时间（忽略时区）。
+-----------+--------------------+------------+
| log_in_id | user_id | epoch_time |
+-----------+--------------------+------------+
| 1 | 1 | 1513242884 |
| 2 | 1 | 1513243489 |
+-----------+--------------------+------------+
但这不会给出准确的结果，因为时区不在UTC附近的人似乎在不同的日子登录。 并存储默认用户时区。
因此问题的下一个迭代是将用户的第一个登录时区存储到表中。
+--------------------+---------------+
| user_id | timezone_id |
+--------------------+---------------+
| 1 | Europe/Madrid |
| 2 | America/Bahia |
+----------- --------+---------------+
这解决了一个问题，但又出现了另一个问题。时区变化的用户（假设他们经常旅行或住在夏令时的区域）仍然无法提供准确的结果。
我能解决的唯一解决方案是在每次登录时存储时区的差异。
+-----------+--------------------+------------+-----------------+
| log_in_id | user_id | epoch_time | timezone_offset |
+-----------+--------------------+------------+-----------------+
| 1 | 1 | 1513242884 | -60 |
| 2 | 1 | 1513243489 | -120 |
+-----------+--------------------+------------+-----------------+
现在使用epoch_time - time*60会给出每次登录的当地时间。
但这表明了另一个问题。用户可以在比时区差异更短的时间内更改到另一个时区。 EJ。用户foo在当地时间14:00登录，然后前往B（在时区中有-1小时）（需要30分钟）并在13:30（B当地时间）再次登录，但真的是30分钟后。这看起来像用户旅行时间。
此时我不知道该怎么办。我想最后一个解决方案是足够的和接近它的“最佳”方式。但我想必须有更好的方法。