Answer the question
In order to leave comments, you need to log in
What is the best way to take into account the user's time zone?
There was a problem with the implementation of a certain functionality. In a nutshell, the task is as follows. The user enters certain parameters, among which is the date of the event (in the future). All this is stored on the server in the database. Then, at the appropriate time (previously entered by the user), something happens on the server.
This assumes access by users from different time zones (other than the server's time zone). Displaying the current server time on the web and forcing you to navigate by it is not very user-friendly. Yes, users are different.
Question. What is the easiest way to make it so that the user can enter his local time and everything works on the server at the right time?
I suppose to store the date in the database in a unix-timestamp, the transfer from the user is in the form of a string like DD.MM.YYY HH:MM, which will be parsed on the server. But this can be freely changed.
The first thing that came to mind was to send the user's time zone offset ( new Date().getTimezoneOffset()
) along with the request, compare it with the server's zone offset, and correct the time of the event passed in the request.
An attempt to understand where the time zone is taken into account or not taken into account during the conversion, and how to do it correctly through date_default_timezone_set
MySQL SET timezone
, was unsuccessful.
Let me know if there are better options. Couldn't find anything on the internet.
Answer the question
In order to leave comments, you need to log in
The user should be able to adjust their time zone in which they record tasks. And it is best to store each task + time offset. Then if the user suddenly changes the time zone, the task will not fail. In any case, I would do so.
In order to perform all calculations in the user's timezone, you can do the following:
1. Data type for the field in MySQL: timestamp
2. Setting the timezone for the connection in MySQL: set time_zone = 'America/New_York' (no GMT+X !)
3 Setting the default timezone in PHP: date_default_timezone_set('America/New_York'); (and again, no GMT+X! this is important)
After that, you will receive all dates from the database in the specified time zone, operations like date('Ymd H: i: s') will also return data according to the specified time zone, save data, you can also directly to the database that came from the user in his timezone.
In order for MySQL to accept Olson DB identifiers (as in paragraph 2), you need to fill in the timezone database (and, for good, do it regularly). Use the mysql_tzinfo_to_sql script from the standard MySQL distribution.
Now about why using offsets (UTC/GMT+X) is bad. Let's say a user requests to create an event that will happen on December 12, 2013 at 10:00 AM. The user's current time offset (which you can, for example, get via javascript) is UTC+3. Does this mean that the event on the server should happen on 2013-12-12 10:00:00 UTC+3? If the user is from Kaliningrad, then yes (since summer/winter time has been canceled in Russia), if the user is from Ukraine (where time conversion is used), then no, the event must occur on 2013-12-12 10:00:00 UTC+2 (because in Ukraine, winter time, UTC + 2, will be used during this period).
Store the date in the database, I assume in unix-timestampVery bad practice. Store time in TIMESTAMP or DATETIME (zone difference).
An attempt to understand where the time zone is taken into account or not taken into account during the conversion, and how to do it correctly using date_default_timezone_set and MySQL SET timezone - was unsuccessful.There is a convenient standard class \DateTime.
I store it in the UT database, give it to the user too, then translate it into the browser's time zone with a script. This method eliminates unnecessary work.
I output something like this:
<span class="time" data-time="<?=time()?>">
<?=date('Y-m-d, H:i:s', time())?>
</span>
<script language="JavaScript">
$(document).ready(
function ()
{
var times = $('.time');
for (var k in times)
makeTime(times[k]);
}
);
</script>
When registering a user, save his time zone in the database. You can find out using JS, or let it be explicitly set in the form.
Further, when the user creates an event, you get the date as a string and, taking into account the time zone, translate it into unix timestamp. Then you work with UT without thinking about time zones.
If your users do not register, request the time zone when creating an event
I store all the time in unix timestamp.
I set date_default_timezone_set() for each user, if the date comes from the user not in unix timestamp - it is assumed that it is in this time zone, the conversion back will be similar for the specified time zone, everything is transparent and simple.
Everything in the database is in unix timestamp, in a BIGINT column.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question