When backdating posts, and supplying the backdated_time parameter as UTC in ISO format, the API does pick up the parameter and creates a post, but date-time of the post is significantly off from the original UTC time stamp provided.
For example:
For a post backdated as 2013-12-18T00:53+0000 Facebook generated post that is 19hours off resulting UTC timestamp would be 2013-12-17T05:53+0000
To make it more clear:
Local time (UTC+11): 2013-12-18T11:53+1100
Posted to FB (UTC+00): 2013-12-18T00:53+0000
Resulting in FB post : 2013-12-17T16:53+1100
(assuming FB converts to my local time zone, as it does to the rest
of the posts)
Any help on workaround would be appreciated!
It's a bug in the Facebook Graph API. Facebook seem to be doing a timezone conversion on a time that doesn’t have (can’t have) a timezone. It seems to be relative to US Pacific local time (currently standard time = UTC - 0800).
I'm in US CST (UTC-0600), so the time I submit is always two hours off. As you’re in Sydney, you're on summer time and 19 hours away from Pacific Standard Time (UTC-0800). Beware that when the US Pacific Time Zone switches to summer time in March the offset will change. It will change again when you return back to standard time in April. (I don't have that problem, because I change standard/daylight in sync with PT.) Also beware that Facebook is liable to fix it in the meantime. (If they’re smart, they’ll change the name of the backdated_time parameter and continue to support it for those of us who are working around the bug.)
Put more succinctly: The offset difference is the number of seconds between the local time set on your account and US Pacific Time zone local time, adjusting each for standard and summer time shifts.
You can confirm this by looking at the HTML in the page. At the time stamp, you'll see some HTML that shows their epoch timestamp, which is different from the epoch time you submitted. In my case, I submitted a value of “1391749200”, while the HTML shows a value two hours earlier, “1391742000”:
<abbr title="Thursday, February 6, 2014 at 9:00pm" data-utime="1391742000" class="timestamp livetimestamp">
I don’t see this problem, however, when setting the scheduled_publish_time (future) value.
Use a page token to post. With page token I get correct timing in UTC, the post is displayed adjusted to my timezone (UTC-6, US Central) Tom
Related
I'm testing some API calls and was delighted to see that the seven-day forecast was including the current day. Around mid-day my time, the seven-day forecast changed and started returning tomorrow as the first day instead.
https://developer.here.com/documentation/weather/topics/example-seven-day-weather-forecast.html
My theory is that the servers are in California (or similar timezone). I'm in Stockholm. It was probably still "yesterday" in the server's timezone when I started playing with the APIs.
Any suggestions on how to fix this? Ideally, I'd like to see an additional parameter allowing me to specify my timezone, or (even better) automatic timezone detection of the requester.
The requester's timezone is not used in the retrieval of the weather data. The reference time(zone) is the local time of the location of which weather data is requested. For the seven days weather forecast, the next day is chosen as the start day if the local time is after 15:00.
Using forecast_hourly as product parameter will give you hourly weather data starting from the current local day and not the next day.
I need an api like the Places Autocomplete but with the place timezone in the response. I could use the Places Autocomplete api, to get the place reference from the response, than the Place Details api to get the longitude and latitude and finally the Google Time Zone API to get the place timezone. Can I do this with a single HTTP call?
If you just need the current UTC offset so you can tell what time it is at that place, you will usually find it in the results from the Details API. From the documentation:
utc_offset contains the number of minutes this Place’s current timezone is offset from UTC. For example, for Places in Sydney, Australia during daylight saving time this would be 660 (+11 hours from UTC), and for Places in California outside of daylight saving time this would be -480 (-8 hours from UTC).
However, as some have commented, and as discussed here, the place details API does not always return the time zone offset.
If it is not returned, or when you need the full IANA/Olson time zone id for the location, you will need to call the Time Zone API as you described.
You may also be interested in one of the other methods to obtaining a time zone from a location, which are listed here.
For example, take this event:
210489449014070 Facebook Event / Graph API Explorer
This event was created back in September 2011. When it was created, it correctly showed Friday, November 11, 2011 11:11pm as the date and time of the event.
But now, it shows Saturday, November 12, 2011 12:11am as the date. This is also happening for future events, such as 426044564103401.
However, it's not happening for even e.g. in the current month like 330237680381087.
Which show the correct date (same as graph shows.) This one was created a few months ago.
My suspicion is that it's still applying the DST offset to the date. For example, right now, pacific time is 7 hours from UTC (because DST is in effect, thus PDT.) On 2012-11-04, DST will end and it will go back to 8 hours from UTC. It "falls back" in fall.
The date on the frontend of Facebook.com is showing as if it's still using the 7 hour offset (it's an hour ahead of what it should be.) My assumption/guess is that at 2012-11-04 02:00:00, it will begin showing the correct date. Hurray? But at that point, the dates that are correct now will probably show wrong (because it won't apply DST anymore.)
I'm guessing this means that internally, timezone-less events are now treated as "-07:00" or "-08:00" globally, based on the current UTC offset, rather than a date-relative one.
Do I have to pull all 186,272 events and update all of them to use timezone dates to fix this (also impacting frontend display to other users, and possibly impacting other parties that are interfacing with these events via FQL or etc.)?
Thanks for any help.
Was probably an issue when Facebook as migrating towards timezone-less events http://developers.facebook.com/roadmap/completed-changes/
Question: If I add an event using the Facebook API today (offset UTC-4 at my location) for an event that occurs in December (offset UTC-5 at my location), will it appear correctly? Or do I have to submit it as UTC-5 in order for it to appear correctly in December, but (possibly) incorrectly now?
Further Details:
On August 1, 2012, Facebook announced that timezone support would be added to events, including through the developer API. In this blog post, they explain how the changes affect reading and writing events.
For the writing of events, you are now required to include the UTC offset when defining the start_time and end_time. So, if I was in Washington, DC (Eastern Timezone and currently on Eastern Daylight Time) and created an event for today, I would input UTC-4. However, if I am creating an event today, and the event date is December 1 (after Daylight Savings Time ends), would I input UTC-4 (the current offset) or UTC-5 (the relevant offset on December 1)?
I realize that there are a lot of questions about Facebook and timezones, but the ones I have found were written before Facebook announced the new timezone support, and so they don't appear to be relevant to this scenario.
From what I have seen, you should be entering the event with the correct UTC offset for the event time you are setting.
For instance, if you had an event in New York City that began at 7pm on 11/3/12 and ended at 7am on 11/4/12 (DST ends at 2am on 11/4/12 in the USA), you would set the start time as 2012-11-03T19:00:00-04:00 and the end time as 2012-11-04-T07:00:00-05:00.
Facebook should display the times corrected for DST.
I'm using GWT on the client (browser) and Joda Time on the server. I'd like to perform some DB lookups bounded by the day (i.e. 00:00:00 until 23:59:59) that a request comes in, with the time boundaries based on the user's (i.e. browser) timezone.
So I have the GWT code do a new java.util.Date() to get the time of the request, and send that to the server. Then I use Joda Time like so:
new DateTime(clientDate).toDateMidnight().toDateTime()
The trouble of course is that toDateMidnight(), in the absence of a specified TimeZone, will use the system's (i.e. the server's) TimeZone. I've been trying to find a simple way to pass the TimeZone from the browser to the server without much luck. In GWT I can get the GMT offset with:
DateTimeFormat.getFormat("Z").fmt(new Date())
which results in something like "-0400". But Joda Time's DateTimeZone.forID() wants strings formatted like "America/New_York", or an integer argument of hours and minutes. Of course I can parse "-0400" into -4 hours and 0 minutes, but I'm wondering if there is not a more straightforward way of doing this.
You could use java.util.Date's getTimezoneOffset() method. It's deprecated, but that's pretty usual for Date handling in GWT currently.
And AFAIR, you can specify something similar to "UTC+4" in Joda time.
Update: I looked it up, and it's "+04:00". Or use DateTimeZone.forOffsetHours() or even forOffsetMillis().
Gwittir (http://www.gwtsite.com) is a library for GWT that includes many cool utilities, like databinding, animation, reflection, and more. However, there are some other interesting goodies as well like the new Joda Time integration. If you have ever been frustrated by GWT’s lack of java.util.Calendar support, you’ll love this, as it makes it easy to do date manipulations in your applications.
otherwise, there are other ways to get timezone offset with + & -.
import java.util.TimeZone;
use: TimeZone.getDefault().getRawOffset()
this function will return the offset time in millisecond about your phone seeting. For Example, GMT-04:00 is equals to (-4)*60*60*1000 = -14400000.
After some operations to get the number which you want.
I have a similar but slightly different problem I think.
I actually need to store the clients timezone on the server, so that I can send out messages about dates stored in their calendar.
The dates are stored in UTC time in google app engine and of course I can store the current Timezone offset when creating the appointment. The problem comes when for instance I want to send out a summary email with a list of upcoming appointments in it. These appointments need to be offset with the correct Timezone adjustments for the client (Im happy to assume that they are still in the same timezone as when they created the appointment).
The real problem comes with Daylight Savings adjustments, so for instance I might have appointments stored for Saturday 30th October 2010 at 1pm (BST[GMT+60]) and Monday 1st November 2010 at 1pm (GMT).
So as you can imagine, I cant just use the current timezone offset (BST) as that would mean that the appointment on Monday 1st November would be listed as 2pm rather than 1pm (GMT+60)
It occurs to me that the best way to deal with this is just to store the timezone offset with each appointment individually, but I feel it would be much better to be able to determine the original timezone correctly in the first place, then just let java do the correct adjustments.