Difference between GMT and PST

Get Started
1

Whats the difference between GMT and PST (Pacific Standard Time) ?

2

PST is 8 hours behind or -8 offset with GMT

3

[LIST]
[][COLOR=#810081]PST (Pacific Standard Time)[/COLOR], as appropriately [URL=“http://www.sitepoint.com/forums/showthread.php?t=450107#2”][COLOR=#0000ff]recalled above[/COLOR] by stymiee, is the time in winter in the “Pacific” US Time Zone; it is 8h behind GMT, i.e. it has a TOG (Time Offset over GMT) of -0800.
[][COLOR=#810081]PDT (Pacific Daylight saving Time)[/COLOR] is the time in [B]summer[/B] in the “Pacific” US Time Zone; it is 7h behind GMT (TOG = -0700). See [URL=“http://www.worldtimezone.com/daylight.html”][COLOR=#810081]Daylight saving time[/COLOR].
[][COLOR=#810081]GMT (Greenwich Mean Time)[/COLOR] is a true definition of a time, with (at the user’s scale) no ambiguity and no change throughout the year, highly useful since clear, simple, world-wide known and understood.
[]UT (Universal Time) is a conceptual error: while pretending to be “Universal”, it already has at least 5 versions, UT, UT0, UT1, UT2, UTC (“Coordinated Universal Time”), see [COLOR=#810081]USNO[/COLOR], [URL=“http://www.worldtimezone.com/wtz-names/wtz-ut.html”][COLOR=#810081]WTZ[/COLOR], [URL=“http://en.wikipedia.org/wiki/UTC”][COLOR=#810081]Wiki[/COLOR]; more, the last (UTC) is actually still not linear since it regularly changes its definition. In short, the 2 final ones, UTC and GMT, can differ by as much as 0.9 sec.; for precize time (e.g. in embedded clocks as GPS), use UTC; for the rest, at the user level (from milleniums to seconds but no further absolute resolution), they have no real difference, so GMT is better for now since the most known and the one understood with the smallest risk of error or misunderstanding.[/LIST]
In the headers of 95% of the email messages in the world, the time is expressed compliant with [COLOR=#0000ff]RFC 2822 §3.3 “Date and Time Specification”[/COLOR], which is named “r” in [URL=“http://fr2.php.net/date”][COLOR=#810081]PHP Date[/COLOR], example:[INDENT]Thu, 21 Dec 2000 16:01:07 +0200[/INDENT]Note that:

[LIST]
[]RFC2822 forbids TZ names (or [COLOR=#810081][I]Time Zone[/I] names[/COLOR], as “PST”, “PDT”, etc.) and forces instead to use [B]TOG (Time Offset from GMT)[/B], which must be expressed, in a fixed-length of 5 characters, with one sign and 4 digits (e.g. “-0000”, “+0100”, “+1000”). This, because [URL=“http://www.worldtimezone.com/faq.html”][COLOR=#810081]TZ are unstandardized, unordered, hence ambiguous and misleading[/COLOR]; in addition TZ combine the definition of a [I]geographical zone[/I] (Pacific for PST) and of a [I]TOG[/I] (-8h for PST), which increases the risk of error (e.g. “[I]Pacific[/I]” is -8h behind GMT in winter and -7h in summer; [I]-7h[/I] is the TOG in Pacific zone as [URL=“http://www.worldtimezone.com/wtz-names/wtz-pdt.html”][COLOR=#810081]PDT[/COLOR] in summer and in Mountain zone as [URL=“http://www.worldtimezone.com/wtz-names/wtz-mst.html”][COLOR=#810081]MST[/COLOR] in winter).
[]RFC2822 forbids names of days and months other than 3-letter English abbreviations (months in digits are one of the main causes for errors in dates; misunderstanding Non-English names is a secondary one; high or various length of names could still worsen the situation).[/LIST]Versailles, Tue 16 Jan 2007 15:04:05 +0100

4

California: we get to work when the Brits drink tea :<

5

This is an Update and addition to my post PST and PDT; TZ and TOG; UTC and GMT; Internet Date & Time; PHP date of Tue 16 Jan 2007 14:04:05 GMT (Sorry for not posting under it, the thread is closed…).

[LIST]
[*]3EN Month: Months must be written in 3-letter English Abbreviations. As an example of “months in digits are one of the main causes for errors in dates” (see post of 2007), “01/02/03” will be read (see Date format by country and its [URL=“http://en.wikipedia.org/wiki/Category:Date_and_time_representation_by_country”]Category):

[]TOG (Time Offset over GMT). As seen in the post of 2007, always include the TOG; don’t omit it, don’t replace it with TZ (see post of 2007).
[]DOW (Day Of Week). Articles and letters too often date themselves with the DOM (Day Of Month) only, and the related events or documents with the DOW only; e.g. NYT in Trapped 68 Days, First Chilean Miners Taste Freedom starts with “Published: October 12, 2010” and continues with “2010 SAN JOSÉ MINE, Chile — With a look of sturdy calm, the first of the 33 miners trapped nearly half a mile underground stepped out of a narrow rescue capsule and onto the surface at 12:11 a.m. on Wednesday”.
So while reading this, you need 1st to check a calendar more than one year back to find that the 12 Oct 2010 was a Tuesday, and the “Wednesday” was on 13 Oct, hence the next-day; then you need 2nd to check a map and a Date and Time site to guess what hour it was actually in Chile or in USA or elsewhere.
What I recommend instead is, when writing, to view the Date-and-Time as an indivisible entity, and to always develop it complete, particularly with DOW, DOM and TOG.
[]USNO page, following a merging of the USNO site into the Naval Oceanography Portal (including changing the “Universal” Resource Locators), has been replaced with another different page, [URL=“http://www.usno.navy.mil/USNO/astronomical-applications/astronomical-information-center/universal-time”]UT. From there you may follow to USNO [URL=“http://www.usno.navy.mil/USNO/time/time”]Precise Time page and to NIST [URL=“http://www.nist.gov/pml/general/time/index.cfm”]Time overview.
[]RFC 2822 §3.3 “Date and Time Specification” is obsoleted (albeit unchanged in this §) by [URL=“http://tools.ietf.org/html/rfc5322#section-3.3”]RFC 5322 §3.3 “Date and Time Specification”
[*]The comma can be omitted. See the PHP example: “Thu, 21 Dec 2000 16:01:07 +0200”. Since the "Thu, " is optional, the "Thu " replacement (sans comma) would theoretically get interpreted as being outside the Date & Time string. So, a parser would, at worse ignore it, at best (which is almost always in facts) understand it the same way as the string with the comma.
[/LIST]Finally I take the opportunity of this unique day when I can ignore RFC’s (and my own!) instruction, and write Month in digits; my signature below will be read the same way by a Japanese, American, European or Australian (and all other bros on the little blue ball):

Versailles, Fri 11/11/11 11:11:11 GMT

6

Next 12x same digit GMT Date-and-Time is Wed 11/11/11 11:11:11 of year 2111

In each century there are 12 dates with the same 2-digit number repeated 6 times; today is one (Wed 12/12/12 12:12:12), next is Sat 01/01/01 01:01:01 of 2101 (Sat 01 Jan 2101 01:01:01 GMT).

In each century there is one single date with the same digit repeated 12 times, last was Fri 11 Nov 2011 11:11:11 GMT above, next is Wed 11/11/11 11:11:11 of 2111 (Wed 11 Nov 2111 11:11:11 GMT).

Versailles, Wed 12 Dec 2012 12:12:12 GMT

7

Threads merged.