#75 elapsed calculation for utc resolved

[SalmanAA]

issue #75 caused because "millisecondsSinceEpoch" is "The number of milliseconds since the "Unix epoch" 1970-01-01T00:00:00Z (UTC)" so comparing two datetimes with different timezones must include "timeZoneOffset" in "millisecondsSinceEpoch" calculation in both "_clock" and "date" parts.

[andresaraujo]

Not sure if this the right approach,

If the date string coming from the server does not include the Z designator when parsing this date it will get interpreted as a local timezone date.

// Reference clock to compare dates
var nowUtc = DateTime.now().toUtc(); // 2019-11-11 15:47:07.000Z - UTC

// A date coming from the server, note this is not UTC because it does not include designator Z
// This will get interpreted as local time
// In my case this would be 2019-11-11 15:15:11 - CST (-6)
var serverDate = DateTime.parse('2019-11-11 15:15:11')

// If I would try to compare a UTC date with a local date, I would get unexpected results if I'm assuming the local date 
// is already in UTC (which is not)
//serverDate calculation is done converting them into miliseconds, which in my case the UTC would be 2019-11-11 21:15:11.000Z - UTC
timeago.format(serverDate, clock: now); // 5 hours from now

In the referenced issue, users want to use the '2019-11-11 15:15:11' data with no TZ information as if it was already UTC, the way to do it is to add the time offset and convert it to UTC.

// Reference clock to compare dates
var nowUtc = DateTime.now().toUtc(); // 2019-11-11 15:47:07.000Z - UTC

// A date coming from the server, note this is not UTC because it does not include designator Z
// This will get interpreted as local time
// In my case this would be 2019-11-11 15:15:11 - CST (-6)
var serverDate = DateTime.parse('2019-11-11 15:15:11')

// Add the time zone offset and then convert to UTC
// This will get 2019-11-11 15:15:11.000Z - UTC
// If I did not add the offset and just convert it to UTC would be the wrong expectation: 2019-11-11 21:15:11.000Z - UTC
var serverDateUtc = serverDate.add(serverDate.timeZoneOffset).toUtc();

// Now with both dates in the same time zone I can be certain of the time difference
timeago.format(serverDateUtc, clock: now); // 32 minutes ago

The question here is, do we make the assumptions all users that pass dates in different time zones want the date calculation to ignore the time offset, as implemented in this PR? My guess is that the right approach is that users should normalize dates so they are in the same TZ before parsing the timeago date.