fullcalendar confusion with UTC and local date

Question

I do let fullcalendar initialize normally. So it represents current date. (Midnight->midnight, 1day, 1h slots)

From some other datasource I get data with timestamps. The format is "YYYY-MM-DD HH:mm" (transmitted as a string, no timezone information)

So I convert that string to a moment object and test against fullcalendar.start and .end to see if it is within.

moment("2016-04-07 00:00") == $('#calendar').fullCalendar('getView').end

This results in false though the following command

$('#calendar').fullCalendar('getView').end.format("YYYY-MM-DD HH:mm")

returns

"2016-04-07 00:00"

I also tried to compare with diff

moment("2016-04-07 00:00").diff( $('#calendar').fullCalendar('getView').end,"minutes")

which returns

Some research on the calendars.end object in Chrome Dev Tools revealed that it internally is represented as

2016-04-07 02:00 GMT+0200

This looks strange to me. I am in timezone 2h ahead of GMT. So it should correctly say 2016-04-07 00:00 GMT+0200, should it not? This also explains why the diff test above resulted in 120 minutes.

Can someone help? I do not get where the conversion problem comes from. I am using only dates with no timezone information. And as said above, fullcalendar initalizes with no gotodate information and shows a time bar from 00:00 to 00:00. So why does it come that there is this 2h difference?

score 2 · Answer 1 · answered Apr 09 '16 at 09:42

Thanks a lot. I do understand things a lot better now. Some of the dates I tried to compare were 'now'. I got 'now' by

var n = moment()

That turned out to be a date time including my timezone.

E.g. moment().format() resulted in '2016-04-07 00:00 GMT+0200' and I now see how this went wrong excepting a comparison against full calendar.end to be true but it was false as '2016-04-07 00:00 GMT+0200' is '2016-04-06 22:00' at UTC.

As

moment.utc()

does not work, I know ended up with using

moment.utc(moment().format('YYYY-MM-DD HH:mm'))

This now seems to work as this treats my local time as it would be the 'numerical same time' at UTC.. thus matching with how fullcalendar handles times internally (ambiguously-zones moments).

Thanks

unfortunately I have to carry the time portion of the date. So startOf('day') will not work in my case. I actually need ambigiously-timezoned "now" — Jens Prystawik, Apr 11 '16 at 09:48

score 1 · Accepted Answer · answered Apr 08 '16 at 16:05

A few things:

The timezone parameter controls how FullCalendar works with time zones.
By default, FullCalendar uses "ambiguously-zoned moments". These are customizations to moment.js made within fullCalendar. The docs state:

The moment object has also been extended to represent a date with no specified timezone. Under the hood, these moments are represented in UTC-mode.

Thus, to compare dates in this mode, treat them as if they were in UTC.
```
moment.utc("2016-04-07 00:00")
```
To compare moments, use the moment query functions, isSame, isBefore, isAfter, isSameOrBefore, isSameOrAfter, and isBetween.

In this case, since FullCalendar's start is inclusive but the end date is exclusive, you probably want to compare like this:

var cal = $('#calendar').fullCalendar('getView');
var start = cal.start;
var end = cal.end;

var m = moment.utc("2016-04-07 00:00");  // your input
var between = m.isSameOrAfter(start) && m.isBefore(end);

Note that there's an pending enhancement to moment's isBetween functionality for a future release that will give you control of exclusivity, but currently isBetween is fully inclusive, so you have to use the combination of functions shown here.

fullcalendar confusion with UTC and local date

2 Answers2

Linked