I am storing the user viewdatetime column from my server time (India), and I want to convert this time depending on the users country. I can get the user country and some details by this steps
Getting visitors country from their IP
Can you give me some suggestion
The best way to do it would be using moment.js library (http://momentjs.com/) and benefit from its Multiple Locale Support.
You should really handle this stuff on client-side (thus JavaScript) instead of server-side (PHP). I hope this answer will be useful.
I guess your viewdatetime column is a DATETIME datatype. If that's true, then the CONVERT_TZ() function will prove helpful. For example, if your user's time zone is Australia/Canberra you can do this:
SELECT CONVERT_TZ(viewdatetime, 'Asia/Dili', 'Australia/Canberra');
But, of course you have to use a public API that guesses the user's time zone from the ip address. Knowing the country isn't enough.
India has a single national time zone. Australia has four. USA has a chaotic set of local rules about daylight savings time, meaning there are roughly twelve distinct time zones. Canada has six zones.
Best practice in this area is to allow each registered user to specify her own time zone preference, and show unregistered users dates and times in your own time zone.
Related
In my system, I am going to use the default time zone as asia/kolkata. If a user accesses from China, is it possible to show the complete system information related to their time zone? How would I implement this?
Note: I am going to use mktime to store all dates in an integer format.
i also using the ip2country to find user country.
i having a big confusion in the part of conversion of the time stamp values, if user 1 post something from India, user 2 view from from china displaying time is based o china.
I'm curious to know if what I'm considering is bad practice, or if since this is a specific and deliberate choice it is actually a decent idea.
I want to store information for dates for events that occur in specific cities. I want to store that data as UTC timestamps.
Wouldn't it be a good idea to simply store the timestamp and the city id/country id (which is associated with a specific timezone), rather than storing the timezone for each event?
I ask because timezones can change, but city IDs would never change in the DB. Once the server is synced with the latest timezone in the (unlikely) event of a timezone change, the event would be independent and unaffected by that change. However, say a timezone changes its boundaries, then events that occurred in that timezone previously could be outside of it.
Does it seem unwise to do this? I'm just wondering, and I've been scouring for best practices but in this case this actually seems like an OK idea. This works particularly because the application design model would never change- events will ALWAYS be associated with a specific city.
The basic flow would be:
Event data with date/location comes into the system in a standard format like ISO-8601 YYYY-MM-DD string.
System converts date to UTC timestamp and stores the date with the event using that timestamp and the city ID for the event.
When a user requests to view that event, the system pulls the timestamp and city information associated with that event, and uses the city's timezone to format the date accordingly on display.
Is this a terrible idea? Is there a benefit to this, and is the concept of storing the TZ Offset the same idea to eliminate this issue?
Scheduling future time is inherently hard, because you don't know what changes are coming in the future. It is a completely different beast than recording past time.
For past time events, all you really need is the local date and time, and the offset from UTC (many platforms call this a "DateTimeOffset").
But for future events, you don't necessarily know what the offset will be. You can guess what it is based upon your current knowledge of the time zone information, but that information is subject to change. In reality, it changes many times per year as governments of the world change their mind about daylight saving time and other situations.
Because you can't determine the offset reliably, you also cannot determine the exact UTC timestamp. So it's important that you hold on to the original local time. If you're going to calculate a UTC timestamp, you should also recalculate that any time you update your time zone data.
I've already written about this multiple times, (here, here and here). I suggest you read those posts.
Now you brought up one point that I hadn't touched on before, otherwise I'd have marked your question as a duplicate. That is - what if the location of the event moves into a new time zone entirely because the time zone boundaries have changed?
I agree with Deceze, that you need to think about how likely this scenario is and how bad a failure would be. In my opinion, it's probably not worth investing a lot of time to. If you have an event scheduled in the future and that location breaks off into a new time zone, you could always go back and edit the event. You need to ask yourself how much detail your app is expected to know about the time zone changes. Most scheduling systems I've worked with don't handle this aspect.
If it is indeed something that you want to handle, then you will need more than just the city. You should store latitude and longitude coordinates for the location. Then you can use one of these methods to resolve the time zone from those coordinates. But also note that you would want to make sure the source of the time zone boundaries was as up to date as possible.
Also note that the IANA Time Zone database that is the original source for the time zone data, does not keep boundary data at all! Most of the boundary data comes from independent sources, such as Eric Muller's shapefiles, which as of today is aligned with the 2013b data of the IANA database (which is at 2013i), so there have been at least 7 updates to the time zone data that either didn't change any boundaries, or the changes were not tracked.
Whichever way you do it, it will fail in different ways depending on what is changing.
If you store timestamps in the according timezone as 2013-12-29 12:34:56 America/New_York, this will fail if, say, the Bronx suddenly starts their own timezone America/New_York_Bronx with a different offset and your event happened to be in the Bronx.
Decide how likely this is and how bad a failure would be.
If you store timestamps in UTC and the timezone in which the event is happening is redefining their offset (e.g. shifting DST dates around, or entirely shifting to a different offset), the event time may differ from the actual wall clock time at that location. If you store 2013-12-29 12:34:56 UTC for an event at 13:34:56 in Berlin, Germany, and Berlin shifts their DST around, 2013-12-29 12:34:56 UTC may now correspond to 14:34:56 Berlin local time, while the event is still actually happening at 13:34 local time.
Decide how likely this is and how bad a failure would be.
If you store the UTC timestamp and link it to a physical location which you then link to a timezone, you can counteract both problems. But for this you'll have to store the precise physical location, not just "New York", otherwise you just have case 1. with one more intermediate step. If you do store the precise physical location and have a precise way to resolve this location to a timezone and you keep your timezone database up to date, you can handle pretty much all change scenarios.
Decide how practical this is and how much this extra precision is worth to you.
When we were migrating our project from UK hosting to US machines, some of the data that was stored as DATETIME was problematic when we had to display data to clients. We had to chage server configuration for time being but it turned keeping dates as strings or date timestamp in db having them dependent from server configuration is not good idea. since then we do use unix timestamps for any dates in the system and we get rid of problem with timezones once for all. Clients decide to use timezone whatever they want to see. It's much easier to calculate time differences, filter data and so on.
The only problem is to make sure entered data into system it's correctly converted to unix timestamp. That means, user who enters the data should have (in your case) event's timezone when date is converted to timezone, otherwise user will need to calculate timezone on his own.
We have been using IPLEGENCE Database pro to get user timezone based on IP address. Here I have a few unusal time zone off sets. Which are listed below
EST+1
PST-2
PST-1
GMT+12.75
I am not sure what exactly above listed off sets.
Could some one please help me in converting the above time zones to UTC.
Thanks for your time.
Here is a list of time zones. EST is almost always (excepting for those DST overlaps) GMT-5. And GMT is either on UTC, or an hour off (again, DST).
EST+1 = GMT-4
PST-2 = GMT-10
PST-1 = GMT-9
The best you can probably do, if you want to convert it to UTC, is to use the DateTime object.
That is rather a strange way to denote time zones. My guess is that GMT+12:45 refers to the Chatham Islands. Not sure about the others, they could be anywhere.
IMHO, there are a few problems with this type of data:
Time zones are not fixed offsets. When the database refers to EST, they probably mean "US Eastern Time". But that could refer to -5 hours offset for Eastern Standard Time (EST), or -4 hours for Eastern Daylight Time (EDT). By calling it "EST" in the data, they are fixing it to -5, when in fact it might be -4. See "Time Zone != Offset" in the timezone tag wiki.
Time zone abbreviations can be ambiguous. For example, how do I know that "EST" really refers to USA's Eastern Standard Time (-5)? It might refer to Australia's Eastern Standard Time (+10). There is a list here, and you can see there are lots of time zones with the same abbreviation.
IP Geolocation is a "best guess", and does not have the kind of accuracy needed to determine time zone. The time zone in these databases may match the listed coordinates, but you have very little guarantee that the user is actually at those coordinates. It might be giving you the location of a proxy server or network router. This is especially true on corporate networks, where (in some cases) you have an IP in a corporate office in another city and all Internet traffic filters through that IP. You're going to get the timezone of that corporate office - not the time zone of the user. You can read more about IP Geolocation Accuracy here and here.
If you know the coordinates of the user by some other means, such as from GPS data on a cell phone, then you can use one of the several different techniques described here.
So I've made a complete system based on/relative to server time assuming that the server time was gonna stay the same and not change. I've used the date() function to get the server time throughout the application. Then we felt the need to cater for different time zones. For example state of Illinois can have two different times zones within the state i.e. eastern time and central time.
Similarly USA can potentially have 5 different time zones within the country.
Now what my approach is that I'd have the user tell me when signing up on my website that which time zone does he come under and based on that, make my calculations relative to his input.
So what I want to know is, how can we cater for different time zones using the date() function. Or if anyone has a better approach to solving this issue, I'm all ears :-)
DateTime::setTimezone
Feed it time in one time zone, set time zone, output time in other time zone. The examples following the link illustrate it very well.
The task:
Time zone chooser widget that allows site visitors to choose their time zone should be generated and populated with reasonable data. It should offer choices like this:
GMT-11 (HH:MM actual time in that zone)
GMT-10 (...)
GMT-1 (...)
... now for the tricky part:
GMT (...)
GMT+1 (...)
... and then all the way until +12.
When user chooses different time zone, server should be able to figure out what time zone to set. This second part isn't much of a problem, once list is populated with correct data.
The problem:
Tricky part is getting actual timezones which are currently in use world-wide. I know how to get entire list of timezones, and how to get their offsets and current DST settings. But, each time zone has two variants: regular time and DST time.
In above list I have marked certain "tricky" part. This is where time zones like Europe/London are. During regular time, Europe/London = GMT, but during DST, Europe/London = GMT+1... Can you see a problem?
What troubles me also is that not all time zones change from DST to regular time and vice-versa, so I can't just populate list with generic data like -11 = GMT-11, -10 = GMT-10, ... and then just apply some logic to locate time zone with appropriate time difference and then set that time zone as a default from that point on.
I'm interested to hear how other sites, that utilize this time zone switching feature, come up with a list of time zones and a logic to choose right time zone, depending on user's choices? Something else you'd like to add or ask?
The most commonly used source for time zone data is the tz/zoneinfo database - it's publically available for free.
As you have noticed yourself, a timezone is an political/administrative entity consisting of a base offset, DST switching dates, and even historical data about changes in these, which you need to correctly deal with historical dates (such as six and a half minutes that officially don't exist).
The tz database (and most apps that use it) therefore represent a timezone not through a base offset, but through the name of the continent and a large City that uses it, often the capital of the country that uses that particular time zone. Examples: "Europe/Berlin" or "Australia/Darwin".
Have a look at what Google Calendar does. It displays the standard time offset as well as the city name, e.g.
(GMT+01:00) Tunis
That seems a pretty reasonable way of representing them, too me. On the other hand, I'm aware that some UIs list the current offset from UTC along with the city. Either way you'll confuse people, to be honest.