Whats the difference between GMT and PST (Pacific Standard Time) ?
PST is 8 hours behind or -8 offset with GMT
- [PST (Pacific Standard Time), as appropriately [URL="http://www.sitepoint.com/forums/showthread.php?t=450107#2"]recalled above](http://www.worldtimezone.com/wtz-names/wtz-pst.html) 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.
- [PDT (Pacific Daylight saving Time) is the time in summer in the "Pacific" US Time Zone; it is 7h behind GMT (TOG = -0700). See [URL="http://www.worldtimezone.com/daylight.html"]Daylight saving time](http://www.worldtimezone.com/wtz-names/wtz-pdt.html).
- GMT (Greenwich Mean Time) 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 [USNO, [URL="http://www.worldtimezone.com/wtz-names/wtz-ut.html"]WTZ, [URL="http://en.wikipedia.org/wiki/UTC"]Wiki](http://aa.usno.navy.mil/faq/docs/UT.html); 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.
In the headers of 95% of the email messages in the world, the time is expressed compliant with [RFC 2822 §3.3 "Date and Time Specification", which is named "r" in [URL="http://fr2.php.net/date"]PHP Date](http://asg.web.cmu.edu/rfc/rfc2822.html#sec-3.3), example:
Note that:Thu, 21 Dec 2000 16:01:07 +0200
- RFC2822 forbids TZ names (or [Time Zone names, as "PST", "PDT", etc.) and forces instead to use TOG (Time Offset from GMT), 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"]TZ are unstandardized, unordered, hence ambiguous and misleading; in addition TZ combine the definition of a geographical zone (Pacific for PST) and of a TOG (-8h for PST), which increases the risk of error (e.g. "Pacific" is -8h behind GMT in winter and -7h in summer; -7h is the TOG in Pacific zone as [URL="http://www.worldtimezone.com/wtz-names/wtz-pdt.html"]PDT in summer and in Mountain zone as [URL="http://www.worldtimezone.com/wtz-names/wtz-mst.html"]MST](http://www.worldtimezone.com/wtz-names/timezonenames.html) 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).
Versailles, Tue 16 Jan 2007 15:04:05 +0100
California: we get to work when the Brits drink tea :<
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...).
- 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](http://en.wikipedia.org/wiki/Date_format_by_country#Map)):
- as (Sat) 03 Feb 2001 by a Japanese
- as (Thu) 02 Jan 2003 by an American
- as (Sat) 01 Feb 2003 by an [European or [URL="http://en.wikipedia.org/wiki/Date_and_time_notation_in_Australia"]Australian](http://en.wikipedia.org/wiki/Date_and_time_notation_in_France)
- 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".
- [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](http://aa.usno.navy.mil/faq/docs/UT.html).
- [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"](http://asg.web.cmu.edu/rfc/rfc2822.html#sec-3.3)
- 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.
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
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