I am trying to add Events To FaceBook with the Time Zone option enabled. I am trying to add Events in UK with time zone as "Europe/London" . This is what I am noticing.
When I send the following Start & End times
[start_time] => 2014-08-24T20:00:00+0100
[end_time] => 2014-08-24T22:00:00+0100
I get the time as
[When]
Sunday, August 24, 2014
[Time]
8:00pm until 10:00pm
when viewed from FaceBook Site. My time zone is set to London which is UTC. But when I send an event in November,
[start_time] => 2014-11-24T20:00:00+0000
[end_time] => 2014-11-24T22:00:00+0000
it is getting displayed as
[When]
Monday, November 24, 2014
[Time]
9:00pm until 11:00pm
Is this an expected behavior. Will the time be adjusted and 8 PM will show correctly on Nov 24th?
Thanks
Lynn
One small correction. You said:
My time zone is set to London which is UTC
The Europe/London zone is UTC+00:00 in the winter, which is commonly called GMT. In the summer it switches to UTC+01:00. which is commonly called BST. It wouldn't be accurate to say that London is UTC. I think you knew this already, I'm just stating it here for others.
Unfortunately, the behavior you describe is expected for Facebook. It comes down to the fact that Facebook doesn't know you are in Europe/London. It simply gets your current time zone offset from JavaScript's new Date().getTimezoneOffset() when you log in. Since it's currently UTC+01:00, that's the offset that is applied to the events when you view the page as a user. It makes a flawed assumption that the offset will not change, or that you won't be looking at future event times until after the next transition.
The Facebook Graph API represents this in the user object. It has a timezone property that is just a number. I guess the Facebook developers haven't read the timezone tag wiki where I make clear that "Time Zone != Offset".
Will the time be adjusted and 8 PM will show correctly on Nov 24th?
Yes. It will show the correct time as soon as the user logs in after the next switch from BST to GMT, which is on October 27th this year.
Related
In my application, I show websites, new IPs that have visited their site. New IPs will need to be shown as each day & unique.
Example:
192.45.11.74 visited 12th November
192.45.11.74 visited 15th November (same user/ip)
I don't want to show the visit on 15th November since it's been registered already on 12th November
This is how I do it:
#visits = Visit.order('started_at DESC').group(:ip)
This gives me unique IPs, but my problem now is when showing IPs for each date, if an IP has been registered 24th September and they visit once again 15th October, instead of not showing that same IP in 15th October (because it has been shown on 24th September), it adds the new date for the IP and shows it again on 15th October (and removes it from 24th September).
PS: Sorry if it's confusing explained
How can I prevent that and only show the IPs that has never been registered for each day?
#visits = Visit.order('started_at DESC').group(:ip).group_by do |visit|
visit.started_at.to_date
end.values.map(&:last)
I want to be able to pull data depending on the time zone I'm currently located in.
For example, I have this query at the moment:
$response = $fb->get('/pageid/insights/page_impressions?period=day')
And I get this response:
But how would I go about showing the data so that it's in Eastern Time (ET) format. Otherwise known as EDT or UTC -4? I'm assuming it's an additional "parameter" added to the query, but what would it be?
Unfortunately, you can't. All data is aggregated by days according to a fixed offset of UTC-7 (even when the Pacific time zone is on UTC-8).
You could adjust the time zone of the resulting timestamp, but that would be misleading, as the value totals would now not truly be matching the days total for the time zone specified.
Really, an API like this (or any operation grouping timestamps by date) should consider a time zone - and that time zone should be specified by full IANA time zone identifier, such as America/New_York. Consider that UTC-4 is not sufficient, because US Eastern Time alternates between EST (UTC-5) and EDT (UTC-4).
You could request Facebook add this feature, but AFAIK they do not currently offer it.
See also this related answer.
This strange behavior has recently came to my attention, while I was testing my Rails app on local environment in which I use around_filter to set the timezone to registered user (the default timezone is UTC).
What I did was that I registered a new user in my app. My current time was 10pm GMT-5 (March 3), and this user's created_at time was saved to database to 4am UTC (March 4). Now, I know that this time is saved in database with the timezone settings, but here comes the problem:
I use a graph for visual representation of daily registered users, and when I called the following function to tell me number of users registered in the last few days:
from ||= Date.today - 1.month
to ||= Date.today
where(created_at: from..to).group('DATE(created_at)').count
It would say that this user was registered in March 4, while it was in fact registered on March 3 from my perspective.
My question is:
How should I call where function and group by a created_at column, so that the dates with be affected correctly (according to my timezone) ?
Or is there something else that I should be doing differently?
I'm not a rubyist, so I'll let someone else give the specific code, but I can answer from a general algorithmic perspective.
If you're storing UTC in the database, then you need to query by UTC as well.
In determining the range of the query (the from and to), you'll need to know the start and stop times for "today" in your local time zone, and convert those each to UTC.
For example, I'm in the US Pacific time zone, and today is March 7th, 2015.
from: 2015-03-07T00:00:00-08:00 = 2015-03-07T08:00:00Z
to: 2015-03-08T00:00:00-08:00 = 2015-03-08T08:00:00Z
If you want to subtract a month like you showed in the example, do it before you convert to UTC. And watch out for daylight saving time. There's no guarantee the offsets will be the same.
Also, you'll want to use a half-open interval range that excludes the upper bound. I believe in Ruby that this is done with three dots (...) instead of two (at least according to this).
Grouping is usually a bit more difficult. I assume this is a query against a database, right? Well, if the db you're querying has time zone support, then you could use it convert the date to your time zone before grouping. Something like this (pseudocode):
groupby(DATE(CONVERT_TZ(created_at,'UTC','America/Los_Angeles')))
Since you didn't state what DB you're using, I can't be more specific. CONVERT_TZ is available on MySQL, and I believe Oracle and Postgres both have time zone support as well.
Date.today will default to your system's set timezone (which by the way should always be UTC, here's why) so if you want to use UTC, simply do Time.zone.now.to_date if rails is set to UTC
Otherwise you should do
Time.use_zone('UTC') do
Time.zone.now.to_date
end
After this you should display the created_at dates by doing object.created_at.in_time_zone('EST')
to show it in your current timezone
We have a web server running Windows 2003 Standard and the time zone is set to GMT-06:00 Central Time, and the box is checked to adjust for daylight saving changes.
A web service on this server queries a datetime field and when the datetime is fetched it is correct. When the dataset is returned to the client 1 hour is subtracted from the datetime if the date is Mar 9-31, Apr 1-5, Oct 26-31, or Nov 1-5. These are the dates that the DST time change can happen on.
It does not matter when the data was saved to the database. If I save a date of 4/1/2013 today, it will be returned to the client minus the 1 hour.
We have verified that SQL is storing the date correctly since it is being returned to the web service correctly.
If I convert the date to a date string at the web server before returning it to the client, the correct date string is returned.
All dates outside of the possible DST dates are good.
All dates during DST that are not on a possible change date are good.
As an example, a date saved as 4/1/2013 12:00:00 AM will be returned as 3/31/2013 11:00:00 PM.
A date saved as 4/6/2013 12:00:00 AM will be returned as 4/6/2013 12:00:00 AM.
I added a web method to the web server to return a date value of Now() and it returns the correct date.
The only thing I have found that is similar was something about a XML rule that says all datetime values are to be transmitted using an offset. I'm not 100% sure but I don't think this is it because only some dates are changed.
Any thoughts/suggestions of what else to look at to get this resolved?
Edit: I have found some dates on the dates listed above that are correct.
I'm going to take a shot at expanding this question, since i've had a similar issue in serialization of data objects.
Take a System.DateTime object that you want to write into a DataColumn. The DateTime object will by default return the DateTime.Kind property as [Unspecified]. When the DataColumn is then set to this DateTime object the DataColumn has a DateTimeMode property that resets to [UnspecifiedLocal].
There is not offest during serialization of DataColumn when the DateTimeMode is [Unspecified] or [UTC]. But when the DateTimeMode is set to [UnspecifiedLocal] or [Local], the offeset is applied. This is where the time can go up or down depending on the timezone or daylight savings configuration.
Sad news is that I can share your problem, but don't have a decent solution. Hope this helps your search.
I can only think of some ugly solutions, but i have not tested any. If i find an elegant solution i will try post again.
I get current UTC time to be used internally from a Windows service application using GetSystemTime API. But I'm curious, is the time returned by that API Daylight-saving independent?
PS. Let me explain what I mean. Say, I call GetSystemTime and it returns 01:59:00 AM on the day when the Daylight-saving should take effect at 2 AM. I then call this API again in 2 minutes later (after the Daylight-saving change.) Will the second result be 2 minutes apart from the 1st result, or will Daylight-saving change be reflected in it?
UTC is ... UTC
Daylight saving
UTC does not change with a change of seasons, but
local time or civil time may change if a time zone jurisdiction
observes daylight saving time (summer time). For example, UTC is five
hours ahead of (that is, later in the day than) local time on the east
coast of the United States during winter, but four hours ahead while
daylight saving is observed there.
Your local time is an offset, and daylight savings (which is a local phenomenon) only changes the offset.
There is no such thing as daylight savings time in UTC.
However, there are occasional leap seconds. The last leap second was added on June 30, 2012 at at 23:59:60 UTC. Time at the end of that day went from 23:59:59 to 23:59:60 before going to 00:00:00 July 31, 2012.
Use something such as Atomic Time if you want a leap-second free time standard.