Issue 336: Respecting timezones for server/client
Status:  Released
Owner: ----
Closed:  Aug 2013
Reported by sriram.v...@gmail.com, Feb 12, 2010
Hi,

I have the time coming in from the database as -

2010-02-03 16:25:00.000

The actual event on the calendar is being rendered as 

2010-02-03 21:25:00.000

Is there some option for the fullcalendar that I am missing? This was
working till 1.3 version.  I just upgraded to version 1.4.

Any help is appreciated.

Thanks,
Sri


Feb 12, 2010
#1 yowza...@gmail.com
I believe FullCalendar is working as it should in this case. Your not really using a 
supported date format. Because there is no time zone information, Full Calendar is 
doing what it can to parse the data and then puts it into the UTC timezone. So it 
converts that date to the correct representation based on your browser's locale.

This is in the docs regarding what date formats will work:

When specifying Event Objects for events or eventSources, you may specify a string 
in IETF format (ex: "Wed, 18 Oct 2009 13:00:00 EST"), a string in ISO8601 format (ex: 
"2009-11-05T13:15:30Z") or a UNIX timestamp.

I'm sending dates from my backend like this:

  "end" : "Mon, 01 Feb 2010 22:50:00 PST",
  "start" : "Mon, 01 Feb 2010 17:50:00 PST",

I think FC could probably do with some additional date related enhancements, but in 
any case, you still need to get your backend to specify a timezone.




Feb 15, 2010
#2 katie.e....@gmail.com
As I noted on an earlier issue, this can be confusing to many people.  I and others
have had to do back-end conversion of the seconds since the epoch (passed, as far as
I can tell, in GMT) to the server timezone to get requests to work correctly.  While
I can understand the fullcalendar API needing to be timezone agnostic in a way, the
behavior ought to be documented.

As yowzator said, a timezone fixes display problems, as the calendar accounts for it
on displaying dates.
Feb 26, 2010
Project Member #3 adamrs...@gmail.com
i think fullcalendar's behavior (literally parsing the date, ignoring gmt offset) is a 
good default, but i agree, there should be a setting to turn on which forces 
fullcalendar to take timezone offsets into account, respecting the server and client's 
timezones.
Summary: Respecting timezones for server/client
Status: Accepted
Mar 11, 2010
#4 urkle0
Here is a patch that adds the ability to "adjust" the ignoreTimezone setting for an
ISO8601 date as read from events.  It still retains the default of ignoring. Just add
a new option of ignoreTimezone: false to disable the current behavior.

0002-Allow-the-ignore-timezone-setting-to-be-adjustable-w.patch
1.9 KB   View   Download
Aug 7, 2010
#5 jmohs...@gmail.com
Any idea when this will be offered as part of a full release? I just ran into this issue creating schedules for college soccer teams across the US.
Aug 8, 2010
#6 jmohs...@gmail.com
One other note:  I took your changes and manually put them in fullcalendar.js.  My UTC dates from the UTC were all handled except those dates falling in the Midnight to Midnight:59 range (00:00-00:59).  These dates would not render in the 20:00-20:59  EDT range; they were just ignored.  Any date before or after was now correctly showing up.  I don't have too much time right now to investigate your code but I wanted to put this out there. For the time being I will do the conversation on the server-side and send EDT dates to the calendar. Thanks.
Sep 14, 2010
#7 urkle0
I can not recreate your issue with dates between 00:00 - 00:59 not showing up right.

Can you provide an exact event record that caused that issue?  The dates I'm feeding into it look like this.

Start: 2010-09-09T00:15+00:00
End: 2010-09-09T00:45+00:00

And this shows up correctly as 20:00 on my local box (Currently in EDT).

The issue with the default behavior of ignoring timezones (which is a BAD default IMHO, make the user specify timezones) and specifying EDT, is that if a user who is not in EDT goes to the website all of the times will be shown in EDT and not their local timezone.   For my web application I Want them to show up in the users local time, so I need this ability..   And I'd prefer to specify nice ISO 8601 dates instead of unix timestamps.   Which would be the other workaround to this issue..  Simply only specifying unix timestamps which doesn't fall into this "ignoreTimezones" trap.  

Oh, and my patch applies cleanly to the 1.4.7 release as well.

Oct 12, 2010
#9 luem...@gmail.com
Extended the Patch (in 'Date Parsing') for the Unix timestamp for myself:

if (typeof s == 'string') {
  if (ignoreTimezone === undefined) { ignoreTimezone = true; } 
  if (s.match(/^\d+$/)) {
    if (ignoreTimezone) {
      var date = new Date(parseInt(s) * 1000);
      offset = 0 - date.getTimezoneOffset();
      return new Date(+ date - (offset * 60 * 1000));
    }
    else { return new Date(parseInt(s) * 1000); }
  }
  return parseISO8601(s, ignoreTimezone) || (s ? new Date(s) : null);
}
Oct 16, 2010
Project Member #10 adamrs...@gmail.com
ignoreTimezone has been added to version 1.4.8 (just released). thanks a lot for the help! please post any issues.
Status: Fixed
Aug 13, 2013
Project Member #11 adamrs...@gmail.com
(No comment was entered for this change.)
Status: Implemented
Aug 13, 2013
Project Member #12 adamrs...@gmail.com
(No comment was entered for this change.)
Status: Released