See some discussion in T7944, particularly T7944#194982.

I've take a look at T7944#194982 and from my understanding you are waiting for some use case to select the best approach.
In my case it's a really simple one and corresponds to display a widget of timeline events, so it's a "kind" of Absolute events.
As I work in french, an iso8601 date representation would be appreciable in order to convert to french date representation.

In any case, example you give in this commentary match my needs.

Please, let me know if you need more details.

Thanks,
Arnaud.

@20after4, just a heads up about this per discussion in T7944. Here's what we expose today:

...
    {
      "id": 5,
      "type": "CEVT",
      "phid": "PHID-CEVT-mqebyeqx7flz4km6fcl5",
      "fields": {
        "name": "October 7th",
        "description": "",
        "isAllDay": false,
        "startDateTime": {
          "epoch": 1475852160,
          "display": {
            "default": "Fri, Oct 7, 7:56 AM"
          },
          "iso8601": "20161007T145600Z",
          "timezone": "America/Los_Angeles"
        },
        "endDateTime": {
          "epoch": 1475855760,
          "display": {
            "default": "Fri, Oct 7, 8:56 AM"
          },
          "iso8601": "20161007T155600Z",
          "timezone": "America/Los_Angeles"
        },
        "spacePHID": "PHID-SPCE-plg2qshv7yqgwy3beo7i",
        "dateCreated": 1475852255,
        "dateModified": 1475852255,
        "policy": {
          "view": "users",
          "edit": "users"
        }
      },
      "attachments": {}
    },
...

The startDateTime, isAllDay and endDateTime fields are the new/interesting ones.

The *DateTime fields have several different representations of time information, so you can select whichever representation is best for your use case. In particular:

• epoch is the epoch timestamp of the relevant time.
• display.default is the way we would render the date in the Phabricator UI, according to the caller's preferences. This is affected by the user's settings: if you change your settings, the way this date is formatted will also change. You should not attempt to parse this field: it is provided for convenience so you don't have to render anything if your client doesn't want to deal with date/time stuff (we may add some other options here, like display.full including an explicit timezone, if there are use cases).
• iso8610 is the ISO8601 version of the date. This may be in the form "YYYYMMDD" (an all-day event), "YYMMDDTHHMMSS" (a "floating" event) or "YYMMDDTHHMMSSZ" (an absolute event, with the time formatted in UTC). Today, it is not possible to represent "floating" events in Calendar and these events are rare, but once ICS import works it will be possible for these events to appear in results.
• timezone is the viewer's configured timezone, and the timezone which the results were rendered for. For example, if an all-day event takes place on "April 3", the "epoch" field contains the second corresponding to "April 3 12:00:00 AM" in the timezone. If you query the same event with different viewers, the "epoch", "display" and "timezone" fields may change. The "iso0681" field will not (currently), as it always encodes a local time with no timezone or a UTC time explicitly in UTC.

Calendar can not currently represent events with multiple different times in different timezones (for example, a television premier with air date "7 PM Eastern/Central, 8 PM Pacific", where the event start is neither "when the clock says X", nor "a specific second in time", but happens at different times depending on locale). ICS can not represent these events either, and I currently have no plans to implement them since television air dates are essentially the only use case I can come up with for them. However, if we do eventually implement them they could cause the iso8601 field to change depending on the querying viewer.

@epriestley: Sounds good to me, this seems quite sensible in every way.