start_time not corresponding to event's start time - facebook

I'm in TZ Paris (GMT +1) and I fetch some events using PHP.
First, I set the default TZ to Los Angeles :
date_default_timezone_set('America/Los_Angeles');
Everything works fine and I get the correct date/time.
Except for one event : https://www.facebook.com/events/115566628587479/
The event shows : 17:00 – 20:00 (UTC-04)
When I fetch the event using FQL, a start_time timestamp is returned : 1343023200 which is Mon, 23 Jul 2012 06:00:00 PST -> converted to 2012-07-22 23:00:00 by the date_default_timezone_set function.
This doesn't correspond to the event's date/time.
Any idea on where I'm going wrong ?
THANK YOU.

First, I set the default TZ to Los Angeles : date_default_timezone_set('America/Los_Angeles');
Well, that’s your error right there – because when you look up the event with the Graph API explorer, you’ll see hat is has a different timezone set:
"timezone": "America/Montreal"

Related

How to fix incorrect Date due to timezone in Core Data from using Calendar.current.startOfDay?

I have erroneously used Calendar.current.startOfDay(for: Date()) to populate a date attribute in Core Data. This means that when users cross different timezones I may have different dates unintentially stored in the date attribute field e.g.
Timezone 1 - 25th 23:00
Timezone 2 - 25th 22:00
Timezone 3 - 26th 05:00
I need to update the Calendar to use UTC Timezone but I need to also perform a migration so that the existing entries in Core Data read like this…
Result:
Timezone 1 - 26th 00:00
Timezone 2 - 26th 00:00
Timezone 3 - 26th 00:00
What are the steps to perform this migration. If I do a UTC startOfDay on it Timezone 1 would get 25th 00:00 instead of 26th 0:00 which is what it should be. Is it possible to accurately update existing entries?
Edit:
For some context I need a reliable way to get all the entries for the 26th for example. I used startOfDay to store the date as it meant I could query by it too and have the relevant entry returned (at any moment in time get the startOfDay and it will give me the entries for the whole day). For historical dates I can do the same - let's say the user has navigated back 2 days I can take startOfDay and subtract 2 days using Calendar.current.date(byAdding: .day, value: -2, to: date) and query for that.
So now the timezone breaks the above logic but is there some way to fix this? If I loop through the entries I can figure out the date it was supposed to be for and perhaps change the attribute to a string - e.g. 26-05-2021 or start to store day, month, year instead and query that.
From reading your answer Duncan I don't think I want to use UTC calendar as it would start to store the entry against the incorrect date from the users perspective dependent on their timezone e.g. user moves to next day and utc is still on previous.
Edit 2:
In a migration I will take the date that is stored and map it to new day, month and year properties storing those instead by getting them from Calendar.current.dateComponents([.day, .month, .year], from: date). Then instead of query by date I will query by day month and year of the Calendar.current where the user is. The side effect here is there is potential the user adds something for today (27th) changes timezone and sees 26th data but I don't think it can be avoided and the old data will then show as intended.
If you took the current time and used Calendar.current.startOfDay(for: Date()) to calculate midnight in the user's local time zone, you have a loss of information. You don't know what time of day the operation was performed. If you saved the time of day in the local time zone in another field, you could reconstruct a Date in UTC.
It isn't clear that what you did was wrong. The day, month, and year is only meaningful in a specific time zone. I am in the Washington DC metro area. We are in daylight savings time (EDT). It is currently 20:56 on the 26th of May. However, it's 1:56 AM on the 27th of May in London, 2:57 AM in Munich, and 3:57 AM in Tel Aviv. All at the exact same instant in time. In UTC it is 0:57 AM on the 27th of May.
Most people think of the calendar date in their local time zone. That is their frame of reference. If you ask me the date right now, I'll tell you it's the evening of the 26th of May. Unless I know you are in a different time zone, that's the "right" answer to me.
If I start out at midnight on a given day in my time zone, calling Calendar.current.startOfDay(for: Date()) each hour, I'll get midnight that day for all 24 hours in my local time zone. For the first 20 hours of the day, that would be the same result I would get if I created a Calendar in UTC and made the same call. However, at 20:00 EDT, I would start getting the next calendar day if I made the same query in UTC.
If you don't know what time of day you made the call to Calendar.current.startOfDay(for: Date()), there is no foolproof to figure out the day/month year in UTC at the instant you made the call. It depends on the time of day in the local timezone, and that timezone's offset from UTC.
Consider this code:
var calendarUTC = Calendar(identifier: .gregorian)
if let utcTimeZone = TimeZone(identifier: "UTC") {
print("Valid time zone")
calendarUTC.timeZone = utcTimeZone
}
print ("Start of day in UTC is \(calendarUTC.startOfDay(for: Date()))")
print ("Start of day in local time zone is \(Calendar.current.startOfDay(for: Date()))")
That outputs:
Start of day in UTC is 2021-05-27 00:00:00 +0000
Start of day in local time zone is 2021-05-26 04:00:00 +0000
That's because right now, which is 20:56 on 26 May in my time zone, it's 0:56 on 27 May in UTC. So if I ask the UTC calendar for the start of day for now (Date()) I get midnight on 27 May, in UTC.
If I ask the same question of my local calendar, I get midnight on 26 may in my time zone, which is 4:00 AM on 26 May in UTC.
If I ran the same code this morning at 8:00 AM in my time zone, I would have gotten the output:
Start of day in UTC is 2021-05-26 00:00:00 +0000
Start of day in local time zone is 2021-05-26 04:00:00 +0000
(Since at 8:00 AM on 26 May in EDT is also 26 May in UTC.)
It's tricky and not 100% reliable and only works if you know that all days were created using startOfDay. But first you need to decide what you want. Say one date was created at 10pm in the New York, and one at exactly the same moment in London, at 4am the next day. What day do you want to be stored?
If your date stored is 25th, 10pm, then you know it was created in a timezone where the day started at 10pm UTC. You are lucky, there are only two time zones that would have created this, one without DST, one with DST. So you know it happened in one of these two time zones, within 24 hours.
Unfortunately, time zones cover 26 hours. Fortunately, only some islands in the Pacific Ocean have same time and different dates (+13 and -11 hours). For these places, you cannot possibly know which date is correct, but very few people would be affected.

Getting List of Timezones in xcode

I am able to get list of timezones using
NSArray *timezoneNames = [NSTimeZone knownTimeZoneNames] ;
The issue is that the list is generated based on the current date set on device. I want this list to be generated using a future date, so that it correctly reflects the applicable Daylight Saving Offset.
e.g. If I use the APP in May 2012 the timezone entry for Chicago is
America/Chicago (CDT) Offset -18000 (Daylight)
and if I use the same APP in February 2012 the entry for Chicago is
America/Chicago (CST) Offset -21600
Can I change the System date within my code so that I can generate the list for any particular date at will?
Sanjay

What is the difference between Facebook start_time in Events table and on FB event page?

I'm using explorer to test this event
FQL to Event table : fql?q={'events': 'select eid, name, start_time from event where eid = 359724487410779'} - returns start_time = 1337410800
Converting 1337410800 gives Saturday, May 19th 2012, 07:00:00 (GMT)
Event object in FB api explorer: https://graph.facebook.com/359724487410779 - returns start_time = 2012-05-19T00:00:00
Event object in browser: https://graph.facebook.com/359724487410779 - returns start_time = 2012-05-18T14:00:00
FB page https://www.facebook.com/events/359724487410779 - Friday, May 18, 2012
11:00pm until 4:00am in UTC+02
How can I get the right local time, like on FB Event page (Friday, May 18, 2012
11:00pm) based on Facebook API ?
Event table - it contains time of the event (in GMT) if it would be in Pacific zone (see here) - so 1337410800 will give you May 19th 7am in GMT -> which is May 18th 11pm in PST - which is the time of the event if you remove timezone.
Event object in FB api explorer - it returns time converted to YOUR Facebook profile time zone - which gives me 2012-05-18T17:00:00 for example (EST). Again, this converts to May 18th 11pm in CET
Event object in browser - i.e. direct call to FB API - gives you start time in PST time zone (2pm PST -> 11pm in Europe/Amsterdam timezone)
FB page obviously have LOCAL time
Answering your question - personally I would go with Graph API call and will convert start_time from Pacific into UTC. Then use "timezone: Europe/Amsterdam" to convert UTC time into local time.

facebook api date format

I've been working on facebook application. But I've faced with strange bug(?).
It I'm trying to get detailed info about any event using graph api start_date differs from the one if I'm trying to get it using fql. for example:
https://graph.facebook.com/209798352393506/ - start date is 2011-05-26T19:00:00
https://api.facebook.com/method/fql.query?query=select%20eid%2C%20name%2C%20tagline%2C%20pic%2C%20host%20%2C%20start_time%20from%20event%20where%20eid%20%3D209798352393506 - start time is 1306461600. Which in human readable format equals to Fri, 27 May 2011 02:00:00 GMT.
As you can see difference between got dates is 5 hours. Somtimes I'm getting dates which differ for 8 hours, sometimes - 6.
Correct date is the first one:
http://www.facebook.com/events/209798352393506/
I can't figure out what happens. All events I'm trying to view are from Denmark. My timezone is Europe/Kiev. Difference is 1 hour.
Is this a facebook's bug? Or documented feature? Or am I doing something wrong?
Link to the documentation or another answer in stackoverflow would be enough.
Here is two events
http://www.facebook.com/events/290600150977115/ - starts on 2012-03-22 at 20:00
http://www.facebook.com/events/289501924395338/ - starts on 2012-03-03 at 21:00
But. Using FQL I'm getting that first event starts on 2012-03-23 at 04:00. Difference is 8 hours. And the second one starts on 2012-03-04 at 06:00. In this case difference is 9 hours. Why???
It was because of daylight saving time.
Time difference between me and facebook(Los Angeles) sometimes was 8 sometimes 9 hours, because there was a moment when Denmakr alredy changed their time to summer time and los angeles - not.
The problem occured when event started "in winter time" and finished in summer time. In this case I needed to add one hour.
Facebook is weird.
From /fql/insights/
The end of the period during which the metrics were collected, expressed as a unix time (which should always be midnight, Pacific Daylight Time) or using the function end_time_date() which takes a date string in 'YYYY-MM-DD' format.
2011-05-26T19:00:00 ===> 2011-05-26T19:00:00 PDT ===> Fri, 27 May 2011 02:00:00 GMT.

Time stamp issue while adding event in facebook using graph API

What is the valid format for start_time and end_time while adding an event using graph api ...
i tried adding an event using unix time stamp .. however its not showing the same date when the event is published ..
when i give start_time as 1293802200 which is 31st Dec 2010 07:00 pm .. it shows as 31st Dec 5:30am on facebook ..
what is it that am doing wrong .. do i need to consider time zone issues as well ??
Regards
Abhishek Jain
According to http://developers.facebook.com/docs/reference/api/event/ it seems that you need to specify date in the Pacific time zone (PST).
Now, the timestamp value you provided is 31st Dec 2010 19:00 in India indeed which corresponds to same day, 5:30 in Pacific time.
In conclusion, convert your local time to Pacific time (PST) prior to uploading it to Facebook.