Facebook timezone issue
From WebOS Internals
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.
The definition of Unix epoch time
Wikipedia rightly defines 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
- Note that the start_time and end_time 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 Date: 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 <start_time> and <end_time> 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 local_time_of_event+8. Bizarre.
Firstly, some definitions:
- The time as stored internally on Facebook servers
- Function to convert to Unix epoch time
- Function to convert to UTC 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:
fb_stored_time = epoch(UTC(assumed_Pacific_time))
(To be continued, not finished.)