Is GMT same as UTC?

Question

I am running a world targeted website where people from all over the world visit. The database contains time in International Date Line West format. I am taking the user time zone using JavaScript and converting the time in the database to user's time and then showing on the page. I want to ask that is International Date Line West is correct format for world level website? Or setting to UTC or GMT will be better? And what is the difference between UTC and GMT and International Date Line West? Are these three same? Finally what time should I set onto my server that will be converted using offset of timezone of user?

Solution 1

If you're interested in astronomical observations, for example of satellites such as GPS, or if you want to cite a technical standard (ITU-R TF.460-6), then you might care that we use UTC and that GMT no longer has a precise definition. Otherwise you probably consider GMT to be the same thing as UTC, and also consider UT and UT1 to be the same as UTC — which technically they are not.

Also, if you're tracking computer criminals or other distributed activity, then you need to determine whether certain events at various sites may or may not have occurred before certain other events. For that purpose you will want to learn and use Network Time Protocol (NTP). That will have a much bigger effect on your understanding of time than the little differences between UTC, UT1, and UT.

"International Date Line West" is just a friendly name for a timezone where the time is defined as twelve hours less than UTC (that is, UTC-12).

Solution 2

UTC is effectively the new name for GMT. It has very minor differences, but none that will impact you in that scenario.

Servy's comment is completely wrong saying GMT includes daylight savings. That's a different timezone called BST that the UK moves to from GMT over summer.

Solution 3

Usually when you have to present dates or times to people in different timezones what you should do is save all time information in UTC on your database and convert it to the users timezone on the display layer (when your presenting the information to your user)

However you will find a couple of challenges: - The timezone you get from javascript may not be trustworthy - Finding the location of the user through the IP and then getting the timezone is also not trustworthy

A good approach in my opinion is to use a "best guess" to find the default timezone (javascript timezone should suffice) and give the user the ability to actively configure his timezone.

On some google applications their approach is to prompt the user for his timezone before starting, this should be done only when you can guarantee that you don't have to repeat this every time the user visits your site (through user accounts or cookies)

Comments

[cernunnos]

UTC uses leap seconds to compensate for the irregularity of the earth and suns movements, this means that sometimes a minute in UTC may have 59 or 61 seconds. However, because it is based on zero degrees longitude, which passes through the Greenwich Observatory, it happens to usually match GMT. Note that UTC has no daylight savings time.

[Shiva Pareek]

What about International Date Line? Can you tell me what's that?

[cernunnos]

That one is easy to find on google :) en.wikipedia.org/wiki/International_Date_Line

[Shiva Pareek]

Ya I already read that but I am unable to understand that its a time zone or what? Should I set that? Because my server is in that time zone currently.

[Shiva Pareek]

But in that case we have to set cookie for unregistered and database entry for registered. But as of my experience, some people even don't know what's timezone? ...then what about them..So we want to take care of all these issues

[cernunnos]

You missunderstood. All date and time information is saved as UTC in the database. When a user visits your site you convert that date time information into the timezone of the user. The idea is to guarantee he doesnt have to know much about timezones, all dates and times presented to him are in his timezone.

[Shiva Pareek]

I don't think so..because my database doesn't save time in UTC. It saves in my local time. that is Indian time.

[cernunnos]

You can force your database to save it to UTC by either configuring it to use UTC timezone as default (my.cnf) or sending "SET time_zone='+0:00'" with every connection.

[Jasen]

How is it a friendly name? I would have expected UTC+12 (eg: Suva)

[Artem Novikov]

It doesn't answer the question. Is it the same or not?

[Chad]

Actually, it's not a renaming: GMT is a timezone, and UTC is a time standard. See timeanddate.com/time/gmt-utc-time.html

[minopret]

Oops, I used pronouns "which" and "they" in an unclear way. I was thinking of all of "GMT" (by a definition such as, mean solar time at Greenwich meridian), UTC, UT1, and "UT" (by any of its other definitions such as UT0). While all of these approximate each other, much of the time their exact values are all different.

[CᴴᴀZ]

@Jasen Going by the Time Zone rules, International Date Line East should be UST+12

[Jasen]

@CᴴᴀZ Suva is West of the IDL but IDLW describes a zone thats that's east of the date line.

[Jasen]

UTC+12 is ambiguous, POSIX and ISO have opposite interpretations.

[minopret]

@artem-novikov The difference that I proposed was, whether the definitions have a generally recognized authority. Examining further, isn't GMT a "mean time" as in mean solar time? That's timekeeping with respect to the average solar day, the period between noon times, when the Sun crosses of the plane through Earth's poles and some other location for observing from Earth. One second would equal 1/86,400 of it. In contrast, UTC is defined in the international system of units, where, in sun or in rain :-), one second is no more and no less than 9 192 631 770 cycles of a Cesium atomic clock.

[Basil Bourque]

@ShivaPareek You may be using the wrong data type in your database. In databases that comply with the SQL standard, such as Postgres, a column of data type TIMESTAMP WITH TIME ZONE will save a moment with respect for the input’s time zone or offset-from-UTC — in most databases this means using the provided zone/offset to adjust the value to UTC before storing. In contrast, the data type TIMESTAMP WITHOUT TIME ZONE ignores any zone/offset info provided with an input, and instead stores simply the date and time-of-day.