My favorites | Sign in
Project Home Issues
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 738: Specify a different working timezone than the browser timezone
13 people starred this issue and may be notified of changes. Back to list
Status:  Released
Owner:  ----
Closed:  Jun 2014


Sign in to add a comment
 
Reported by yowza...@gmail.com, Nov 30, 2010
Adam,

This is related to  issue #280 , but that issue has been marked as done. I think FullCalendar still needs more robust Timezone support. For instance, the following assumptions would be fairly standard in a modern webapp:

* All dates are stored on the server in UTC
* Both the app server and database server are running in UTC
* Users of the webapp select their TimeZone, which is stored in their user profile
* Users could have a local system timezone that is DIFFERENT than their profile timezone
* All dates in the application are displayed in the the timezone specified in their profile
* FullCalendar gets event feeds from the webapp via a RESTful API that always outputs times in UTC ("Sun, 07 Nov 2010 12:00:00 UTC"). This is because the API also needs to interact with other clients.

So in most cases, the user specifies the same timezone in their profile as the timezone on their system. And everything works nicely.

BUT... when the timezone on the system is different than their profile's timezone, then all dates in the application are shown correctly, except for the dates in FullCalendar. This leads to confusion and mistakes.

What is needed is a way to specify to FullCalendar what the intended display TimeZone should be so that it can convert the event feed times (UTC with assumptions above) into the user's PROFILE timezone, instead of their system timezone.

One option I'm considering doing is adding a parameter to the REST API that specifies the timezone to return the results in (?start=...&end=...&timezone=America/Los_Angeles). But it seems like there should be a way to just tell FC to use a specific timezone.


Dec 22, 2010
Project Member #1 adamrs...@gmail.com
i totally agree.

is is already possible to send utc events to fullcalendar and have them rendered in the user's browser's timezone. you need to set ignoreTimezone to `false`:
http://arshaw.com/fullcalendar/docs/event_data/ignoreTimezone/

i know it would make sense for ignoreTimezone to be `false` by default. i'm going to make this change in the next version.

i totally agree that events should display in a timezone that is *different* from the user's system's timezone. however, to get this to work all in client-side js, you'd need to have info for *every* possible timezone. this project tries to solve this:
https://github.com/mde/timezone-js
but requires a big js data file.

if i were to pursue this client-side route, i'd like to make it an optional extension. could be a cool sub-project.

however, i still think the best place for this timezone-conversion stuff is on the server-side. you could have your server-side script output dates that are in the desired local (and preserve that by using ignoreTimezone=true)

let me know what you think. thanks!
Status: Discussing
Mar 30, 2011
#2 codychar...@gmail.com
Has anyone successfully implemented timezone-js (date.js - https://github.com/mde/timezone-js) with full calendar? As soon as I add  timezone-js, fullcalendar breaks.  

I agree with the above comments that there should be a way to override the client timezone and use some predefined or user selected offset. 
Mar 31, 2011
Project Member #3 althaus.it
I'm with Adam and would do it on the server side.
Jun 19, 2011
#4 James.Bo...@gmail.com
watches is one of the important factors in our daily life.Original watches are always very expensive compared the replica watches.so that is why there are many people like the replica watches,especially the top quality grade replica watches.http://www.bwo888.com is a very professional top quality swiss grade replica watches supplier who can sell many very fashion and classic replica watches.,including top quality and  most popular,classic and professional watches brands,such as Rolex,Patek Philippe, Omega,Audemars Piguet,Breguet,Breitling, IWC,Cartier,Panerai,Tag Heuer,Hublot, Chopard,Montblanc,and so on.For our profession and long-term reputation in this filed and market.

http://www.bwo888.com
Jul 4, 2011
#5 VMickevi...@gmail.com
A little bit different suggestion, but regarding the same topic.

I wish there was an option to ignore all this timezone-related stuff for those, who don't need it. I mean when fullCalendar gets unix timestamp (seconds after 1970.01.01), it should just display it, without any adjustments based on server and especially client/browser timezones. I mean when unix timestamp "1" is given, it should treat and display it as "1970.01.01 00:00:01", and not for example "01:00:01" or "02:00:01". Tried ignoreTimezone true/false - didn't seem to make any difference (changing client pc time-zone still changed times displayed).

I believe this to be nearly a "must-have" feature. Because I think in most of cases, projects are small, meant to be used inside single country. And in that case, no one wants to have all the trouble with clients having wrong timezone set on their machines (this happens often, not all of them even know what timezone is, where it is changed on their operating system, etc.).

Or am I missing something here? For example, maybe this simplified(?) scenario requires timezone-js libraries mentioned, etc.?


Jul 17, 2012
#6 amitav...@gmail.com
Any update on this? As previous comment says, when I pass unix timestamp from server, client timezone settings screwing up the event (ignoreTimezone true/false makes not difference).
Jan 27, 2013
#7 kshe...@livingtree.com
Any update on this? I am surprised that this is an issue in fullCalendar.
May 20, 2013
#8 jfr...@gmail.com
Hi, I posted a possible solution here: 
https://code.google.com/p/fullcalendar/issues/detail?id=576#c3
Jul 9, 2013
#9 sidar...@gmail.com
Great idea to implement timezone-js, however what about simply allow to pass time difference between user desired timezone and with UTC to calendar and that's it?
Aug 13, 2013
Project Member #10 adamrs...@gmail.com
(No comment was entered for this change.)
Summary: Specify a different working timezone than the browser timezone (was: Specify a different working TimeZone than the browser TimeZone)
Labels: Type-Feature
Aug 15, 2013
Project Member #11 adamrs...@gmail.com
 Issue 1262  has been merged into this issue.
Aug 25, 2013
Project Member #12 adamrs...@gmail.com
 Issue 1957  has been merged into this issue.
Aug 25, 2013
Project Member #13 adamrs...@gmail.com
 Issue 1977  has been merged into this issue.
Sep 1, 2013
Project Member #14 adamrs...@gmail.com
(No comment was entered for this change.)
Labels: milestone-date
Sep 2, 2013
Project Member #15 adamrs...@gmail.com
Please read my proposal for a date system overhaul for fullcalendar, as it relates to this issue:

https://github.com/arshaw/fullcalendar/wiki/Proposal-for-a-date-system-overhaul

Please let me know what you think!
Sep 3, 2013
#16 flip...@gmail.com
The proposal looks good, though i still have to figure out whether it's compatible with some scenario's. Especially when having a shared calender between people from different timezones and people who will travel outside their regular timezone.

==== My own Scenerio's (not sure if all are possible)
1.
Times from different timezones not converted to a common timezone. This could be handy when wanting to compare day schedules of people in different regions. But actually comparison is best done with two calendars, or not even a calendar. Putting this in the same calendar, i think, will be confusing. So conclusion: don't make this possible.

2.
The timezone to be converted to should default to the browsers default timezone, but should be able to set a different timezone so that you can see how things would work out when being in a different timezone.

3.
When viewing a calendar with events from multiple timezones, the events that have a different timezone then the current timezone of the calendar (see 2) should have a visual indication of the original non-adjusted time. Of course the visual implementation is left to the programmer, but fullcalendar should be able to provide two times (the original and the adjusted one).

4.
Fullcalendar should have reliable detection for timezone and DST. Default JS implementations can be buggy, that's why there are scripts like JsTimeZoneDetect http://pellepim.bitbucket.org/jstz/ Fullcalendar could have optional dependecies on these scripts.

==== Comments to proposal
A.
"Make sure the feed script is aware of the timezone we want to operate in, via an additional GET parameter ("timezone" in this example)."
Why should the server take care of the conversion to the wanted timezone? Server should be able to send a bunch of events each with their own timezone, the script can then convert it to the view-timezone.

B.
"If we simulate another timezone in the browser, the today date might be different, at most off-by-one. Maybe add an option to set the current todayDate."
No. It's natural that Today can be different when viewing events in another timezone. This is not needed. The programmer could display a clock of the other timezone to make it even more clear that now (today) is at a certain time.

C.
"Implicit allDay value"
This is nice. Is it possible to have implicit allDay value with start and end?

D.
"Also, the iCalendar protocol does it this way too."
Yes __any__ compatibility enhancement with iCal is really good.

E.
"Google calendar implements this, and events must end before 10am the next day. I think we should make this the default."
10am that's 10 additional hours, while DST is usually just 1 hour, and in very rare cases more then that, why does it have to be 10 hours? Can this setting be adjustable?

F.
"Include both Moment's and jQuery UI's pre-packaged translation files as-is"
This is good because then the responsibility of the translation stays with the respective package.

"Include FullCalendar's translation files, which are a merge of the two. Both Moment and jQuery UI translations will also be initialized."
Don't see the point of having 2 translation files, and then a 3rd translation file which is a merger of the first 2, and then including them all 3.
Sep 3, 2013
Project Member #17 adamrs...@gmail.com
@flip101, your scenarios:

1. Yes, FullCalendar will render these events, but they will be normalized to UTC first, then normalized the brower's local timezone. I think this should be possible. (I see this relates to question #3)

2. Yes, possible by what I describe here: https://gist.github.com/arshaw/6420506#other-timezones

3. Not possible because usually when a date is parsed, it uses the offset string (like "-06:00") to normalize the date to UTC, and then throws it away. A date object, whether it is JS's native Date or a Moment, is not linked to any particular timezone, so this might be hard to implement. Even if it were possible, I'm not sure the user experience for this would be the best. The UI would probably be too confusing (each event displays two times?)

4. I disagree that this should be FullCalendar's responsibility. In the browser, in JS, representing timezones other than the local one is really hard. As you mention, there are projects that do this (in addition to Moment-timezone), but that leaves the user to download extra data files. These data files are very annoying to maintain. There are hundreds of them, and the data can actually *change*. The Olson database (which dictates these offset and DST for every region) gets updated regularly. You'd have to recompile your JS data files every time. It is best to leave this to the OS and whatever server-side language you're using. (related to me solution in https://gist.github.com/arshaw/6420506#other-timezones)
Sep 3, 2013
Project Member #18 adamrs...@gmail.com
@flip101, in response to your comments:

A. This is a bad idea for the reasons I previously mentioned about timezones on the client.

B. Not sure I understand. We can have more discussion here: https://code.google.com/p/fullcalendar/issues/detail?id=593 (12 people already want this feature)

C. If there is a string like "T00:00:00" in either the start or end ISO8601 string, the date will be considered allDay=false

D. Agreed

E. I was thinking of making it an adjustable setting, but just have 10am be the default.

F. You'd include either Moment's configs +  jQuery UI's configs. OR you can include ONLY FullCalendar's. You'd never need to include all three. I'll update the proposal to make this more clear.
Sep 4, 2013
#19 flip...@gmail.com
1. I was talking about a situation where they would not be normalized (that should not be happening). So it's good to know they will be normalized.

3. Not displaying the same event twice. Suppose the user is on CEST time (+0200) and is viewing a shared calendar. Someone from new york (-0400) planned an event in the morning at 08:00 his time. Only one event shows up in the normalized user timezone at 14:00. But when the original time is available with the event object the programmer can then for example make a tooltip saying "This event is scheduled for 08:00 New York time". That will help greatly when having events happening in different timezones.

4. If Moment-timezone has good timezone detection then another library is not needed of course. I did see that JsTimeZoneDetect does rely on the Olson database and Moment-timezone detect doesn't. I'm suggested an __optional__ library to increase accuracy. But perhaps this is a bit if a luxury as Moment-timezone will give the right timezone in almost all cases.

A. "In the browser, in JS, representing timezones other than the local one is really hard". That reads as if Javascript is inferior to server-side programming languages when it comes to doing calculations on datetime. Could you back this up with some examples? When having an ISO8601 timestring like "2007-03-01T13:00:00Z" or "2007-03-01T13:00:00+0800" It doesn't seem too difficult to convert those to a normalized timezone (for example "+0200").

B. As i read the issue, the first post states:
"- i wan't to set it to server current date, but now current date comes from the browser."
This should be fixed by setting the calendar timezone to the server-specified timezone instead of the local browser timezone.

C. This example here https://gist.github.com/arshaw/6420506#implicit-allday-value does not show an end date. So i was asking if an end date is supported.

F. The translations should stay with the owning library and not be copied to another library as this will give problems with updating and possibly slower updates. Fullcalendar should have a requirement for the right library versions to use, in case the used library (jQuery UI, moment, or another) changes some features or translation and will be incompatible with fullcalendar's code at that time.
Sep 4, 2013
Project Member #20 adamrs...@gmail.com
3. I see. This could be implemented with functionality FullCalendar already has. The timezone string (like "America/New_York") should probably be sent down in each Event Object as a custom property. Then, the custom rendering via the `eventRender` callback could read this property and do what it likes.

4. They both rely on the Olson database. They both have a build process that converts the Olson database into JS that can be processed. Moment-timezone just makes it more seamless.

BTW, I plan on relying on Moment, but NOT Moment-timezone. Multiple timezones are best supported a different way, outlined in the "other timezones" section of my proposal.

A. JavaScript definitely IS inferior. It doesn't know how to display dates in a timezone other than UTC or the browser's local. A timezone is more than just a single offset (like "+0200" in your example) but rather multiple offsets that change at arbitrary points in time for DST. Thus the Olson files that are needed. In other programming languages, this Olson data is encoded into the primitive date objects. JS Dates don't have this feature.

C. yes, end dates will still be in FullCalendar and the implicit allDay feature will support them.

F. I'll try to think of a smart way to handle this. Relying on specific version numbers might not be the best way. A smarter type of detection is probably best (the presence of certain translation-file-properties probably).
Oct 16, 2013
#21 ch...@getspokal.com
"however, i still think the best place for this timezone-conversion stuff is on the server-side. you could have your server-side script output dates that are in the desired local (and preserve that by using ignoreTimezone=true)"

This is exactly what I'm doing - and it was working perfectly on my development machine, but as soon as I deployed to servers (system clock set to UTC is the only real difference?) it's converting the time to browser time ANYWAYS, even with ignoreTimezone set to true.  it's killing me. I can take that code out and just output UTC, but then I run into the same possible issues the OP raised - the browser timezone may not be set to the profile timezone and this will lead to confusion.

I'm confused by your answer because based on it my initial solution should work, but it does not.
Jan 25, 2014
Project Member #22 adamrs...@gmail.com
v2.0.0-beta introduces a whole new timezone system:
http://arshaw.com/fullcalendar/docs2/timezone/timezone/

please check it out and let me know what you think
Status: Accepted
Feb 1, 2014
#23 astj...@gmail.com
I like where the timezone handling is headed, however, I am cautious of one detail. I'm not a big fan of how it relies on the name of the timezone.

I understand this is a result of relying on moment.js. I do think this is a mistake though. If instead, the api relied on the offset in terms of seconds or some unit of time instead of a name, things would be a bit less ambiguous and a little more future proof.

I recommend that fullcalendar accept and dish out timezone offsets in terms of a unit of time. That way there is no confusion at all and the conversions on either side are trivial on both server and client side.

Just my 2 cents. Keep up the awesome work!
Feb 3, 2014
Project Member #24 adamrs...@gmail.com
@ashtjoh, I wish timezones were as simple as a single timezone offset, but unfortunately there is DST. We need the full timezone name (like "America/Chicago") to determine when in the year daylight savings time happens, which changes the offset.
May 2, 2014
#25 modi08...@gmail.com
I have a kind of interface wherein i can assign tasks to different users .I am using  fullcalendar 1.6.3 to support my application. There has been a "TIMEZONE ISSUE" to my version of fullcalendar:
As and when i refresh my fullcalendar my events time changes to the time which it was assigned + 05:30..(say i have assigned john a task at 12:30 pm;after refreshing the fullcalendar,the event  would display 6.00 am i.e (12.30 +05:30).Any idea as to what can be a possible fix?
May 25, 2014
Project Member #26 adamrs...@gmail.com
(No comment was entered for this change.)
Status: Implemented
Jun 2, 2014
Project Member #27 adamrs...@gmail.com
version 2 has been released with this change.
http://blog.arshaw.com/1/post/2014/06/fullcalendar-2-released.html
Status: Released
Sign in to add a comment

Powered by Google Project Hosting