This question already has an answer here:
Time difference in PHP using timezone function?
(1 answer)
Closed 5 years ago.
I am building a site that will be accessed in different countries. How do I make the time specific for each country timezone. For example Nigeria is GMT+1 while Ghana is GMT. How do I show time to be 6pm in Nigeria while 5pm for someone accessing the website from Ghana
You can see link:
http://php.net/manual/en/timezones.php
and to use in you php code, you will use :
date_default_timezone_set('Europe/Kiev');
or any country you need .
There are several steps in this process:
Use GMT, otherwise know at UTC, in your code and database.
Detect the country of the visitor, either by IP, or user data.
When outputting a time you convert UTC to the local time of the country of the visitor (see the answer of Ghaly Saqqal).
If you have difficulty, with any of these specific steps, you can ask a question about that.
The most popular (==standard?) way of determining the time zone I've seen around is simply asking the users themselves. If your website requires subscription, this could be saved in the users' profile data. For anon users, the dates could be displayed as UTC or GMT or some such.or
new Date().getTimezoneOffset()/60;
getTimezoneOffset() will subtract your time from GMT and return the number of minutes. So if you live in GMT-8, it will return 480. To put this into hours, divide by 60. Also, notice that the sign is the opposite of what you need -- it's calculating GMT's offset from your time zone, not your time zone's offset from GMT. To fix this, simply multiply by -1.
then use some ajax to set time zone of visitor
Related
I am having an issue getting my head around storing and retrieving information based on a date (no time) and dealing with multiple timezones.
By default my application uses UTC, so create/update times are all in UTC and PHP functions such as date etc all use UTC.
My problem is this:
I allow users to create a news item, the news item has a date (no time, just date).
The application uses UTC, my user is in Sydney, so what I do is when the form loads I pre-populate the date field based of jS M Y for the Australia/Sydney timezone, this way it shows as today for him. All good so far.
When I save the record into the database (into a DATE field) I use the date they entered so if they said 3rd March 2016, then it goes in as 2016-03-03.
When it gets pulled out again it displays fine for them, but if I do a report saying "How many news items published today?", in my report (cron job) it might be looking for a different date, because if this person entered it in early morning, then 3rd March 2016 for Sydney is still going to be 2nd March 2016 in UTC so there will be 0 for today.
The solution it appears would be to convert the date back to UTC when you store it, but how will that work?.. Since it's just a date with no time.
2nd March 2016 00:00:00 UTC would be 2nd March 2016 10:00:00 Sydney
So.. I am not sure how to solve this without them having to also enter a time, which seems redundant.
Always remember that savings time rules vary between countries, such as the USA and EU. Not just when the clocks change but timings of changes across time zones.
In the past I forced a local hour of 12:00 (noon). With a time value the standard conversion routines be used. Choosing noon kept everything well away from any midnight and savings time issues as an hour slip either way would still be in the same day.
The simplest way is to ALWAYS work with full UTC timestamps under the hood.
Convert incoming dates to these straight away, and only convert back to readable, localized formats when rendering.
This way you have a single, solid, point of reference. Everything in your database has logged exactly when it was created (relative to the 1st of January 1970 - UTC).
Then it becomes trivial to order articles in order of creation (regardless of where their authors posted from). It's also much easier to count how many articles were added in the last 24 hours, or on a specific day (for example; seven days ago) -- notice how these examples don't require a date, just ranges of seconds.
This also makes it easy to show "user A" when "user B" added an article, relative to user A's timezone -- you don't need to look up user B's timezone to do the conversion.
Also, give your user the option to add a time to their articles, but don't make it mandatory. Have a sensible default (ideally a dynamic "now"). This is more natural, and should smooth out the midnight and DST anomalies highlighted by Gilbert, when building reports.
It actually sounds like you are doing things correctly already.
The concepts of "today" and a "date" are calendering concepts, covered by the domain of civil time. You can fly around the world with a printed calendar, and you don't need to adjust it for UTC or time zones. A date itself can't be "in UTC".
However, you can say that in the domain of absolute time, that a date in time zone A does not cover the same instantaneous moments of time that are covered by time zone B. At any given time, there could be two different "todays" in effect on the Earth.
By the perspective of your Sydney user, March 3rd was the publishing date. You might have another user in Hawaii publishing simultaneously at March 2nd.
Inherently then, your posting date is the civil date that the item was posted. When you query for all items posted "today", that is based on the civil date of wherever you're at when you're asking.
If this isn't the desired behavior, then change the question. Instead of asking "what was posted today", ask "what was posted in the last 24 hours?" For that, you would indeed need to store the full UTC-based date and time (not just date) of the post. Then you would query it by UTC time from now less 24 hours.
A thought exercise that will help: What should you do if a user posts at 23:59 UTC, and you run a query one minute later? Should it include the result - or not? Does your answer change if it's 23:59 local time and you run the query one minute later in the same time zone? Thinking this through will help you decide what you should actually be storing and querying.
I'll also say that in most cases you should indeed store a UTC based timestamp, but you may want to also store the local date (or datetime) in a separate field. This gives you the ability to do both types of queries.
I ran into trouble while dealing with date and time using php and mysql. I am trying to store local time of user's timezone as a timestamp on mysql db and would like it to convert back to normal date and time at the time of output.
This is the first time I am dealing with date and time.
As I understand: I can't rely on PHP's time() as it returns servers time according to server's timezone and the same case with mysql current_timestamp.
I can use the javascript to get user's local timezone and then can use date_default_timezone_set() for each session.
If I am doing right, now the confusion starts.
As you can understand the users will come from around the globe, so if two users (one from US and another from India) do something at the same time, will it show each others time as identical or it will show some difference? I mean it shouldn't show Indian user that the US user has done something few hours ago as the US user done at same time.
Please let me know if I don't understand these things properly.
What I want to achieve is, the output of the time should show in local time format. Ex: any time should show in IST format for Indian user and other country respectively.
Best way to achieve this is to store date in a database in a standard format (eg. GMT).
After getting user's timezone through javascript, you may convert date to user's timezone & display accordingly.
This question already has answers here:
Should I use the datetime or timestamp data type in MySQL?
(40 answers)
Closed 9 years ago.
I have searched around and haven't found a specific answer to my question..
I am wondering the best practice for storing timestamp information.
Example:
user1 logs in in Florida (-0500) at 3:00pm EST
The admin logs into the system an hour later from California (-0800) at 4:00pm
I want the admin to see the log onscreen and see that user1 logged in 1 hour ago..
My brain is going nuts bc i feel that i am over complicating this..
I should be able to use UNIX time stamp and then adjust with the -0800 or -0300.
Do i store the users timezone offset in their profile information?
Do i store the -0300 with the log entry.
Any input would be greatly appreciated!
You are mixing up client timezone and server timezone.
As long as you do not care where your users sit, you have absolutely no problem as long as you do not change the server timezone. You can set a default timezone in MySQL and in PHP and this one will be used, independent of the timezone of the visitor.
If you want to respect the timezone of your visitors, it gets slightly more complicated. You need do transform a timestamp from one timezone into another. You can find information concerning that in the PHP manual if you want to achieve this with PHP. You can read this SO thread if you are interested in how MySQL stores dates internally (difference between TIMESTAMP and DATETIME type), which opens the possibility to use some of mysql's features, and which you should definitely take into account when you implement a global project.
Timezone can be configured dynamically in the PHP, so you don't need to store time offsets in your DB. Storing unix timestamp is a good solution.
You can store timestamp as INTEGER datatype.
Then, you can use JS on client side to get the timezone of user.
Well I know that this question may be asked many times but certainly I've few doubts In my mind, and by the way don't comment that what I've tried, I've tried many ways but am just asking what's the correct and easier way as there are many posts lingering out here with different suggestions for accomplishing these tasks, so I'll explode() my question into smaller questions...
So can you people just guide me where am going right or wrong as am sure many people are confused when it comes to date/time
1) Why/how to save time as UTC in MySQL using PHP?
Personally for this I post this using php $year/$month/$day and check the date using checkdate() in mysql date field. so is it ok or should I use timestamp and than explode the retrieved string on front end using php?
2) If I run server from India, should I record default time using date_default_timezone_set("Asia/Calcutta"); and than subtract and add time using php function or while posting only I should check users time zone selected from his user accound and accordingly set a condition kinda:
if(timezoneselected == +5.30) {
echo date_default_timezone_set("Asia/Calcutta");
} elseif(timezoneselected == +anytime) {
echo another country timezone
}
3) last question is how websites like gmail facebook etc manages time? I mean if they are saving datetime according to their server than how they show perfect posted time for each user, even gmail, if I send a mail to another user, my sent time and the person living in another country gets email at his printed local time I mean how we can do this, sorry am not able to explain you perfectly say this example,
facebook:
user from India posts, facebook shows posted 8 mins ago, 9mins ago, fine after sometime they show a real date, and that date is perfect according to the time I posted, however if a person from USA updates, say 8 mins ago 9mins ago on his profile but his original posted time is shown correctly to him, and even correctly to me?
sorry for this question but really this will help me understanding this date/time concept and will also be helpful to future users. Thank you!
Bottom line, you should store everything UTC
When you display times for a particular user, use a timezone of their choosing. Store the timezone of the user, like "Asia/Calcutta" and simply convert the time when displaying it using the date_default_timezone_set method.
I will attempt to answer your questions from the comment here.
You store everything UTC always. It is the baseline. When you display the times associated with anything you convert based on the user. If you want to display Posted 8 mins ago then you are taking the delta between the current UTC time and the UTC time associated with a post. If you send a message from user A (in India) to user B (in Los Angeles, USA) then you would store the message time in UTC. If user A is viewing it, the time would be converted to "Asia/Calcutta" and if user B is viewing it, the time would be converted to "America/Los_Angeles". Using UTC will make your life a lot easier. Trust me.
As described in MySQL Server Time Zone Support:
The current session time zone setting affects display and storage of time values that are zone-sensitive. This includes the values displayed by functions such as NOW() or CURTIME(), and values stored in and retrieved from TIMESTAMP columns. Values for TIMESTAMP columns are converted from the current time zone to UTC for storage, and from UTC to the current time zone for retrieval.
Therefore, if you use TIMESTAMP type columns, MySQL will handle timezone conversion for you automatically: just set the appropriate timezone for the session in its time_zone variable.
More I think about this, more it gets difficult
The idea is to have a form where each person chooses his timezone and a time range and days of week available
ex.
Timezone
USA eastern
10pm-11pm sunday(checked) thursday (checked)
Now, someone searching the db from france will set his timezone to be 6hours later
any simple way to do this in php?
every use could be in a different timezone. so hours and maybe day of week will be different.
My personal recommendation would be to do all the storing and processing in the same time-zone (for example, GMT). Then, based on the user's settings simply display the times differently when outputting them to him by adjusting them by the necessary amount.