Bing Maps 7 API bug in MouseEventArgs.getX and getY

The new Bing Maps is a lot more lightweight, and the changes in event handling makes more sense. For example, it is now possible to detect viewchangeend event instead of using an assortment of onendpan, timers and getCenter to detect whether the view has changed.

However, I ran into the same problem mentioned here http://www.ms-windows.info/Help/map-control-v7-mouse-wheel-double-29660.aspx. The mouse wheel and double click do not zoom at the location of the mouse. Worse still, adding a pushpin when the user clicked on the map results in the pushpin being placed too high up on the map. How much higher the pushpin is placed also depends on the browser used.

Upon investigating the MouseEventArgs.getX and getY functions, I found that they depended on getViewportX and getViewportY functions. By replacing the getViewportY function with one that uses jQuery to calculate the correct offset, I managed to get the mouse wheel, double click and pushpins to all work correctly.

var map = new Microsoft.Maps.Map($("#map")[0],

{

    credentials: "",

    center: new Microsoft.Maps.Location(1.35, 103.82),

    zoom: 11,

    showDashboard: false

});

 

map.getViewportY = function () {

    return $("#map").offset().top + $("#map").height() / 2;

};

However, it does introduce a problem whereby the dashboards navigations no longer work correctly and the view type menu displays too far down. It thus necessitates writing my own dashboard.

Oddities of Facebook events API

Using the the Graph API of https://graph.facebook.com/[userId]/events, one can retrieve the events that the user is attending. The same applies to page, using https://graph.facebook.com/[pageId]/events. However, what does it mean by the event attended by a page? It is not the same as the events created by the page, as the API returns less results that what you would see in the events tab of the page. The result return from FQL and REST API are similar.

After spending an entire day figuring out what happens behind the scene, I came to the following conclusion:

1. User A creates Page P.
2. User A makes User B also the admin of Page P.

During creation of event:

1. If User A creates event on Page P, Page P will be attending the event.
2. If User B creates event on Page P, Page P will not be attending the event.

Unfortunately, as FQL does not allow querying the event by its creator, there is hence no way to fool-proof way to get the events that a page has created.

Oddities of Facebook event date/time

Facebook is very popular globally, crossing several time zones. Yet to my surprise, it has no concept of time zones. Quote from the Legacy REST API

Note that the start_time and end_time are the times that were inputted by the event creator. Facebook Events have no concept of timezone, so, in general, you can should not treat the value returned as occurring at any particular absolute time. When an event is displayed on facebook, no timezone is specified or implied.

However, using the Graph API to retrieve events of a page, I got the following:

{
  "data":
  [
    {
      "name":"Event Name",
      "start_time":"2010-11-20T02:30:00+0000",
      "end_time":"2010-11-20T03:00:00+0000",
      "location":"5th Street",
      "id":"1234"
    }
  ],
  "paging":
  {
    "previous":"https:\/\/graph.facebook.com\/11\/events?access_token=15\u00257&limit=5000&since=2010-11-20T02\u00253A30\u00253A00\u00252B0000",
    "next":"https:\/\/graph.facebook.com\/11\/events?access_token=15\u00257&limit=5000&until=2010-09-22T01\u00253A29\u00253A59\u00252B0000"
  }
}

The start_time and end_time are displayed as GMT+0. These times are 8 hours late. On some other events, they are 7 hours late. Clearly, Facebook is trying to store the time in GMT, but isn’t using the correct time zone where I am at.

According to http://www.webos-internals.org/wiki/Facebook_timezone_issue, Facebook assumes all time to be in Pacific Time. Thus the GMT-8 during Standard Time and GMT-7 during Daylight Savings.

In order to use the time from the Graph API, I used the TimeZoneInfo to convert the time from GMT to Pacific Time. Code as follows

private static PacificDateTime StringToDate(string value)

{

    DateTime fakeUtc = DateTime.Parse(value, CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal);

    // See http://www.webos-internals.org/wiki/Facebook_timezone_issue.

    // Facebook assumes all time in events to be in Pacific Time.

    const string pacificTimeZoneId = "Pacific Standard Time";

    TimeZoneInfo pacificTimeZone = TimeZoneInfo.FindSystemTimeZoneById(pacificTimeZoneId);

    DateTime pacificTime = TimeZoneInfo.ConvertTimeFromUtc(fakeUtc, pacificTimeZone);

    return new PacificDateTime(pacificTime, pacificTimeZone.IsAmbiguousTime(pacificTime));

}

By treating all times as Pacific Time, Facebook introduced oddities to places that do not practise daylight savings, or that has daylight savings on a different schedule. Effectively, there is no way for me to meet on 13 March 2011 at 2.30am. Since daylight savings starts at 2am on the 2nd Sunday of March, and it adjusts the clock to 3am, 2.30am is an invalid time in Pacific Time. Events specified as 2.30am becomes 3.30am.

On the 6 November 2011, daylight savings ends and the clock jumps back an hour. This creates ambiguous time between 1am and 2am, which Facebook behaves in a very weird way when creating events that are at that time. Try it for yourself.