Closed (fixed)
Project:
Fullcalendar View
Version:
8.x-2.0-rc9
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
13 Sep 2018 at 16:00 UTC
Updated:
24 May 2019 at 17:07 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
rfulcher commentedI am getting this same behavior.
Comment #3
rfulcher commentedI was able to determine that in my site this line of code was causing the issue, it is on line 180.
$start = $timezone_service->utcToLocal($start_date, $timezone, 'Y-m-d');All the dates that were getting converted were going back a day. Not sure why. I tried to debug it but could not so I just replaced that line with this one for now.
$start = $start_date;I hope this helps.
Comment #4
utcbrij commentedThank you, rfulcher! That worked!
Comment #5
utcbrij commentedComment #6
utcbrij commentedThe start date is good, but the end date is still a day early. Tried editing the end date code in similar fashion as the start date on lines 237 and 257 to no avail. Any ideas?
Comment #7
utcbrij commentedNot sure if this is right, but it worked. Please advise if something else should be done.
Line 237 changed from:
$end = $timezone_service->utcToLocal($end_date, $timezone, 'Y-m-d', '+1 day');
to:
$end = $timezone_service->utcToLocal($end_date, $timezone, 'Y-m-d', '+2 day');
Repeated the same for the range on line 257.
Comment #8
rfulcher commentedThanks for the info on the end date brij2136. I am not using the end date at the moment for my project so I did not even look at that. I assume I will need to at some point. I am not sure why we are getting the result that we are. I am using a custom entity and the definition for my field is below. I don't think there is anything wrong with my entity or storage. I am on the east coast of the United States so Daylight Savings time is a possibility. But right now I have a few deadlines I have to hack it and get it out and maybe can look back at it later.
Comment #9
utcbrij commentedEast coast USA here too. Didn't think of daylight savings being a factor. Thanks for the help. I'm using a custom entity as well, but am new to D8, so I'm still in a learning curve.
Comment #10
eahonet commentedI'm experiencing this same issue. I'm using a content type with a Start Date and End Date and it's all skewed by one day. I setup mine using this tutorial: https://www.ostraining.com/blog/drupal/how-to-integrate-a-calendar-in-dr...
Comment #11
peter caritas commentedI'm also experiencing this problem. I believe it is a timezone issue. I experienced this issue while I was using a Date type field for both the start and end dates and my timezone was set to CDT (US Central time). I changed my timezone to Melbourne AUS and that corrected the display. I assume that's because it's closer to GMT.
The next thing I tried was to use a different field type for the start and end dates. I switched to Timestamp fields for both dates. Now the events were displaying on the correct day when my timezone was set to CDT. However, if I switched to Melbourne, AUS, then the events appear a day later!
So, it appears that there needs to be some improvement to the timezone handling and it needs to take into account the field type. I would be interested to hear from the maintainer about what approach was used. I note the that timezone_service method seems to be have been abandoned in favor of this, perhaps:
gmdate("Y-m-d\TH:i:s", strtotime($start_date))Comment #12
tomhung commentedMy site was doing the same thing. I couldn't find the location of #3 so I overwrote the return of utcToLocal to just return the date submitted. It seem to me that my view is already sending the timezone corrected dates.
Comment #13
utcbrij commentedtomhung, great solution at #12. My date problem came back either after the latest DST change or the latest update; not sure which, but your solution worked for me. Thanks.
Comment #14
utcbrij commentedComment #15
mingsongThanks guys for raising this issue and all the investigations you have done.
Drupal 8 stores all date time field in UTC timezone regardless the timezone of current user. But apparently, in this use case, we don't need to convert the start time from UTC to user's local timezone for some reasons.
I am not able to reproduce this issue on my site. If anyone who is facing this issue could provide more details, that would help me get better understanding what causes this issue. It would be great if you could tell me what value of the start field stored in our database. For example, the value stored in your database is "'2019-02-24T23:00:00'" and the start day appeared in your calendar is "2019-02-25 10:00:00am". That will tell us if the day time stored in your database is the same as it appears in the calendar.
What type of field is the start field and end field? Are they date only? Did you specify the time zone for the user or the default timezone for the entire site? Did you specify the display timezone for the field in the view setting?
The approaches from #3 and #12 are only suitable to the particular use case in which the date stored in the database is not UTC time.
Comment #16
mingsongComment #18
mingsongOk, I got it.
Drupal changed the behaviour that it won't store date only field in UTC time after upgrading to 8.6. It literally store the original date string into the database regardless the time zone.
So I think I fix this issue with the latest Dev.
Comment #19
mingsongComment #20
mingsongReleased with 8.x-2.1
Comment #21
utcbrij commentedPerfect, Mingsong! Works like a charm! Thank you!
Comment #22
utcbrij commentedSpoke too soon. Trouble on the ipad. Only showing "Select Language" dropdown?
Comment #23
mingsongSorry, do you mean that a calendar view render correctly on computer browser, but in the ipad, only the language dropdown show up?
Did you login the website on your iPad? I am wondering if it is a user role issue rather than a cross browser or responsive view issue.
If you could give me more details, that would help the investigation.
Comment #24
utcbrij commentedNo, I'm not logged in on the ipad. It worked on my Android, though. I had to go back to #12 for the time being.
Comment #25
utcbrij commentedAnd it worked on the desktop, iMac and PC
Comment #26
mingsongI got it. It is a cross browser issue with JavaScript ES2015 (ES6).
There is a similar issue raised here #3043799: Not supporting IE 11 version.
I fixed it with version 8.x-2.2.
Comment #28
carroll_webprog commentedHello - I fixed this issue by changing some settings.
In my case, I have my site settings set to a default time of 'Denver' - (US Mountain Time). My dates are stored in 'Denver' - (US Mountain Time) in the database, but on the FullCalendar View they were being displayed as UTC - which for me, is 6 hours earlier.
Originally, on the FullCalendar view I created, I had selected 'Denver' as my timezone under Fields->My Event Date Field.
In the Full Calendar View, I changed the timezone setting to UTC instead of Denver under Fields->My Event Date Field.
The FullCalendar View displays the time correctly on the view now. This is how I resolved this issue. I hope this helps someone else. Thanks.