Entries aren't rendered with the correct timezone

Thanks Sally.

Can someone test it with different timezone from server's one?

Hi!
I could test these changes, as this problem is actual to me.

How do I get this as a patch? I'm having trouble displaying dates in full calendar cos I'm in BST (UTC+1) in the summer! Setting my site and computer to Reykjavik(Iceland) GMT without any summertime offset fixes my problem that I thought was with BAT/BEE. Please can I get this soon.

The source code looks good to me.

I merged it into 5.x branch, so that it is easy for those want to test it.

You can download the latest develop version from https://www.drupal.org/project/fullcalendar_view/releases/5.x-dev

In which the fix is in place.

Please let me know how it works to you.

Works! Thanks.

I'm still experiencing the wrong time displayed on calendars. If I open an anonymous/private browser and display the calendar - the time is off by -7 hours. I've tried disabling user timezone, and changing system timezone but the time displayed in the calendar continues to be off by that specific amount.
If I login as admin to my site I still see the wrong time displayed in the calendar. The time on the event record itself shows and updates perfectly (and even reflects the difference showing the local and event times.)

After 2 hours of testing - I reverted to 5.0.8, and applied the Timezone patch. and my problem disappeared. As a side note, I will add that changing the local server and browser timezone did NOT have any effect.
I am watching the 5.x dev release as it has a fix that I'm hungry for - but can live without. Also, I see what is happening with the fullcalendar 5 libraries and I really do hope to see those someday soon.

I noticed after upgrading Fullcalendar View to 5.1.0 that dragging and dropping existing Smart Date nodes in my calendar causes the time to be incorrectly offset by the timezone. Reverting to 5.0.8 fixed the behaviour.

It is a bug related to this change.

I uploaded a patch to fix it.

You can get the patch from https://www.drupal.org/project/fullcalendar_view/issues/3219378#comment-...

Please let me know if it fixes this issue for you or not.

The fix is released with 5.1.1

I have checked carefully my configuration- maybe it is something I am doing wrong - but my calendars are still off by the offset.

I checked my server php.ini, machine timezone and user account timezone. I tried all set to UTC, and all set to Los Angeles.
The content properly reflects the information for an event entered. the fullcalendar doesn't. It is always off -7.
I made sure the patch 3219378 was applied. I went back and hand applied Sally Wu 5.08 patch (the thread says it is installed but the patch actually isn't the same as the 5.1.1 code)

I can't think of anything else I can do. I am sure to clear cache, browser cache and have advagg and performance cache disabled. I clear it each time and test.

I'm going to try the dev fork as a last effort before reverting to 5.08 with Sally Wu patch which was the last thing that worked for me. I realize the drag and drop was fixed, but my users don't use that so I can hold on. Time problems are always rough and over my head!

update: Tried 5.x dev and continued to have problem. Have reverted to 5.0.8 with patch.

I've uploaded a screen grab (with 5.1.1) in case it shows something important - the textual of the event is shown above the calendar showing what is expected, the event in the calendar showing 3am (-7 offset).

Also - the patch https://www.drupal.org/files/issues/2021-06-18/fullcalendar_view-3219378... was what I applied to 5.0.8 to be fixed - NOT the https://www.drupal.org/files/issues/2021-05-26/fix_fullcalendar.patch patch.

Thanks Jim for your feedback.

Are you saying 5.0.8 + patch (https://www.drupal.org/files/issues/2021-06-18/fullcalendar_view-3219378...) is working for you?

Hi Mingsong - thanks for your attention - I know it sounds wierd but yes. that is exactly what I am saying! Accidently, I did not put the Sally Wu patch back in my composer, I left the newer patch. I did not expect the patch to apply, and I did not expect the 5.0.8 to work without the Sally Wu patch.
As you can see in my upload "composite.jpg" - I show the composer info, the composer.json patch section and the screen result of the site all functional and correct.
Because of your response, I wanted to dig deeper. I am about to tear the patch out and test, and switch the patch with the sally wu patch to see what the results are of each combination. One thing I did was to remove the 5.0.8 via composer and then require it so I could document the composer results for you. Those results are in 'remove-require5.0.8.jpg' so you can see the screengrab. I will try and get more useful information over the next few hours.

Testing results - done carefully as I could:
5.0.8 - no patches
cleared browser cache, full cache cleared (also tested not clearing browser cache)
works.
5.0.8 - Sally Wu patch
cleared browser cache, full cache cleared
works
5.0.8 - 6/18 patch
cleared browser cache, full cache cleared
works - color me surprised!

5.1.0 - no patches
cleared browser cache, full cache cleared
fails - calendar event time off by -7 hrs.
5.1.0 - Sally Wu patch
cleared browser cache, full cache cleared
fails - composer reports could not apply patch.
5.1.0 - 6/18 patch
cleared browser cache, full cache cleared
fails - calendar event time off by -7 hrs.

5.1.1 - no patches
cleared browser cache, full cache cleared
fails - calendar event time off by -7 hrs.
5.1.1 - Sally Wu patch
cleared browser cache, full cache cleared
fails - composer reports could not apply patch.
5.1.1 - 6/18 patch
cleared browser cache, full cache cleared
fails - composer reports patch cannot be applied.

dev-5.x - no patches
cleared browser cache, full cache cleared
fails - calendar event time off by -7 hrs.
dev-5.x - Sally Wu patch
cleared browser cache, full cache cleared
fails - composer reports could not apply patch.
dev-5.x - 6/18 patch
cleared browser cache, full cache cleared
fails - composer reports patch cannot be applied.

Did more testing and digging - My server is a local Dev server so the date/time of it is directly tied to the same date/time as the browser. More important - my offset and how it is derived:
I am in Pacific Standard Time (PST) - or UTC(-8:00). In my timezone I also have a Daylight Savings Time (+1 hr). Hence the -7 offset from the UTC time stamp data for my event.

I ran debugger on the .js but didn't really see anything of value. (not good at debuggers). I did note the 'timezone' variable is misspelled as timeZone - but this seems to have no impact. Windows machines are notoriously case sensitive!

Not sure what else I can do to be helpful -but I'm willing to try anything.

Hi Jim,

Great job. Appreciate the test you have done for this module.

At the moment, there is no patch that can be applied to 5.1.1.

This patch 6/18 patch (https://www.drupal.org/files/issues/2021-06-18/fullcalendar_view-3219378...) has already been pushed into 5.x and released as 5.1.1. Additionally, this patch only works for drag and drop feature. If you are not using this feature, nothing to do about this patch.

According to the test result, may I ask following questions?

1. Is the browser timezone same as your server's timezone?
2. Did you try drag and drop and a calendar entry?
3. When it is fail, Are event are presenting in the browser's timezone or server's timezone, or neither?

Thanks again.

Mingsong - this morning I modified my environment so I could verify answers to your question. I now use 2 workstations - 1 as server and 1 as browser - they are separate windows 10 machines with firefox. The web server is a WAMP64 server running as localhost.

1. In all previous posts and tests, I was using the SAME machine to do both server and browsers.
2. I have applied both patches on 5.0.8 and tested drag and drop. It does not work for me. The time changes on the event. This testing is not very complete. I then installed 5.1.1 with no patches - and the Drag and drop functionality worked for me BUT this is only when the browser and server were the SAME machine.
When I used my dev web server with a 2nd workstation, I encountered problems of time changing on the Drag and drop feature. However, this is a bad test as my .htaccess and the php.ini files for the dev environment are not setup for this correctly and it would be a difficult effort to get fixed for a valid test.
3. During the time failure of 5.1.1 (not the drag and drop feature) - using a separate workstation did NOT affect the incorrect time display. I believe you can safely assume the problem is server side.

I am NOT a programmer - I was reviewing the original posters reference to fullcalendar api specifically the v5 timezone documents - I feel like I'm up against a problem using UTC when I should be set to 'local'. Just my thought :).

I am going back to 5.0.8 with 2 patches for now. that is my most stable situation. Do you feel this should be a separate ticket? The orignal ticket is marked closed ...

Last piece I can provide today -
I've been experimenting with all sorts of fiddling to see if I could affect the time. I found something that may help to shed light on the problem source.
My site normal does NOT display the timezone of the event record during creation. I enabled display of timezone in the record creation and was surprised to see 'UTC' as the value that was displayed. The calendar showed the correct time (using 5.0.8 with both patches).
I changed one record timezone to 'Default (Los Angeles)' - and my fullcalendar would NOT display! I believe since my data is legacy there may never have been an actual stored timezone in the record initially, OR the timezone stored was UTC. I am seriously considering pulling out all Events (100's of them!) and recreating them after putting 5.1.1 in place to see if my problem goes away. I am a Smart Date user and this may be a self-inflicted wound... Thoughts?

By any chance, could you try 5.1.1 + patch from https://www.drupal.org/files/issues/2021-06-23/fullcalendar_view-3220098...

And let me know how it goes.

I would appreciate that.

No joy. I spent most of the day trying many things. When I'm external to fullcalander all values show and reflect properly; IE; I created views to display tables of the events. All my views showed perfectly.
I cleared all the records and recreated just a few test records.
I checked config.date in d8 to verify it was set to America/Los_Angeles.
I checked the users - testing both with and without default settings. (overriding Admin is hard!) No impact.
I ran timezone tests on my php server. I changed my PHP server default from UTC to America/Los_Angeles. No impact.

I created records with 'Default - America/Los_Angeles', 'America/Los_Angeles'. When I set the user to 'America/Detroit', the record that showed 'America/Los_Angeles' changed by +1, however the Default record did NOT reflect this time difference.

When I change records to UTC, they display correctly HOWEVER, this causes a duplication of the time showing both the event time and an "(time in UTC zone") which I can not use as the extra content blows layouts and looks horrid in general.

I did review some notes on D8.9 and D9 core changes to Timezone detection but I don't believe they actually apply.

I began creating new content that was not based on Smart Dates but I am a bit frustrated ATM. I appreciate all you do Mingsong, so I really wanted to at least isolate the area of my problem but I can't define why this is happening! I'll revisit this at a later date.

Fresh head and all that -
This AM I was planning on building a virgin test site with only the 2 modules so I could dig hard. As I began documenting I was reviewing the View that creates my fullcalendar_view table.
In the block view there is Format: Full Calendar Display : Settings
In Settings, there is a sub section for Display
Inside of Display is 'Time Format settings for month view'.
In my working environment (5.0.8) I had 'h a' entered. The calendar event time showed '10a'.
In the failing environment (5.1.1) the display showed '3a'.

I emptied this field. The 5.1.1 display changed to '10a'!
I put 'h a (z)' so I could see the impact and the display said '3 a (UTC)'.

SO!!! Finally. The problem is the Time format setting of MomentJS's formatting are causing a revert to UTC. ANY value in the field causes the time to be incorrect! It properly updates the time display, but the value seems to revert to UTC.

Further experimentation shows that there is clearly the problem here. IF MomentJS shows UTC, then the offset value should be -00:00 but it is not! I've attached a screen cap to demonstrate. (even better, the View preview lets us see immediately the result of the test and no cache clear is needed!)

Other problems actually become apparent - the help text says the default is 'hh:mm a" when in fact it is 'ha' if there are no minutes to display.

So. I feel I should move this to a new issue - I can actually live perfectly fine with no Time format setting as the default is exactly what I need. However, my site is intended to be used as a model for multiple companies in different time zones and being able to display the 3 digit time zone will be critically important.