Difference between revisions of "Facebook timezone issue"

Revision as of 09:32, 30 January 2010

Introduction

This article has been moved to my blog.

http://geeklog.lucid.net.au/article.php?story=20091211084306281

@@ Line 1: / Line 1: @@
 == Introduction ==
-As at version 1.3.1, Synergy and the Pre doesn't display Facebook event times right.  This is, in my opinion, due to an error on both the part of Facebook, and Palm.
+This article has been moved to my blog.
-Mostly Facebook.
+http://geeklog.lucid.net.au/article.php?story=20091211084306281
-== The definition of Unix epoch time ==
-Wikipedia rightly defines [http://en.wikipedia.org/wiki/Unix_time Unix epoch time] as:
-:'''''Unix time''', or '''POSIX time''', is a system for describing points in time, defined as the number of seconds elapsed since midnight Proleptic Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds.''
-The key point here is that an epoch timestamp is in ''UTC time''.
-== How Facebook does event times ==
-As per http://wiki.developers.facebook.com/index.php/Events.get:
-:''Note that the <tt>start_time</tt> and <tt>end_time</tt> returned are the times which were input by the event creator, converted to UTC after assuming that they were in Pacific time (Daylight Savings or Standard, depending on the date of the event), then converted into Unix epoch time.''
-... Pacific time being GMT-8.
-Why they assume this PST timezone, who knows... their backend seems to be smart enough to work out what timezone a typical browser session is in (I'm assuming via +/- offsets in <tt>Date:</tt> HTTP requests), so why not use that when an event is submitted, convert down to UTC at ''that'' time, and all is well!
-Instead, they do it this way, and do some crazy magic when others view the event.  This is where I say Palm is partly at fault -- because they haven't put this same magic in.  They shouldn't ''have'' to though.
-== What WebOS does ==
-It would seem the Pre assumes that the <tt><start_time></tt> and <tt><end_time></tt> are in UTC via a Unix epoch timestamp -- very fair logic in my opinion, as this is what Facebook ''should'' be returning via its API.  Instead, it seems to return <tt>local_time_of_event</tt>+8.  Bizarre.
-Firstly, some definitions:
-;fb_stored_time
-:The time as stored internally on Facebook servers
-;epoch
-:Function to convert to Unix epoch time
-;UTC
-:Function to convert to UTC time
-;assumed_Pacific_time
-:Facebook being stupid and assuming the local time the creator entered is in Los Angeles -- ''yes America, we all live there''. This time can be affected by daylight saving, too
-So the math loosely looks like this:
-:<pre>fb_stored_time = epoch(UTC(assumed_Pacific_time))</pre>
-''(To be continued, not finished.)''

Difference between revisions of "Facebook timezone issue"

Revision as of 09:32, 30 January 2010

Introduction

Navigation menu

Search