@DavidO - i am still working through this but this is something to look at
@DavidO - I have found something interesting. If I log into chrome with our pack g-account here is what the calendar shows for your pack:
The same thing holds true for my pack as well
@DavidO - and found this:
https://support.google.com/chrome/thread/95893021/wrong-time-on-all-google-websites?hl=en
1 Like
Good find! I wonder if that’s it?
But this is in Safari mobile. 5PM-8AM…
I think Edge and Brave are now Chrome/ium based, but I didn’t think Safari was.
This is Brave mobile. 5PM-8AM…
So on iOS browsers… Safari and Brave are 5PM-8AM and Edge and Chrome 11PM-2PM.
Some consistency, but nothing correct. One hour could be daylight savings related?
@DavidO - just for the fun of it… could you try those browsers in private or incognito mode and see what the results are ?
1 Like
@DavidO - interesting factoid… when logged into chrome the time is converted to UTC so my 7pm meetings become 11pm. As it notes at the bottom left of the calendar events shown in Coordinated Universal Time Time
Doesn’t seem to much matter. Or at least I can’t affect it much. Both my device, my setting, and my current location are all central time zone.
I think the difference has to do with standard time versus daylight savings time as 5PM-8AM “sprung forward” becomes 6PM-9AM, which is correct. If someone is using the iCal feed directly, then it will likely be correct, at some point (I haven’t tested that). Just like the website one will, once CST has “sprung forward.” But until then it’s going to show an hour off (at least, some of my views were 6 hours off) and anyone manually entering events based on the text is going to have it wrong.
It’s as if it doesn’t know that it will “spring forward” by then and UTC-6 Central (Standard) Time time will give way to UTC-5 Central Daylight and show correct. Because of this, I think we are stuck showing that it will be a different time (1 hour off) than it will actually be once we “spring forward.”
Is there a fix?
Versus
@DavidO - certainly not one for scoutbook to fix. I know as long as i do not log chrome the times are correct. I primarily use chrome not logged in along with firefox and opera. All of them show it correctly. You may want folks to subscribe to the url. There really is no fix for the use of UTC that I have found for logged in browser sessions
For clarification, when you say “show correctly” what times are they showing?
What timezone are you in?
@DavidO - i am in New Jersey so Eastern. I posted the screen shot of your pack calendar and the times looked correct for you. Once i log into chrome i then see the utc time shift that you originally posted. So not in any way shape or form a scoutbook calendar or url subscription issue.
I would suggest posting to the browser help desks.
Would you mind letting me know what you see here?
https://calendar.google.com/calendar/embed?src=b24d9r3g9dmsks9nq42o9d60hu6f2hta%40import.calendar.google.com&ctz=America%2FChicago
I’m showing correct in that view on my desktop.
…and my phone.
That calendar specifically says “Events shown in time zone: Central Time - Chicago” at the bottom, which show the correct 6PM - 9AM time. I assume you’ll see CT times also, not ET adjusted times. I just wish the website would do the same thing.
It appears to be an issue with the Google Sites calendar widget.
@DavidO - here is what I see as of 4:52pm today
1 Like
I thought I found a fix. This was disabled by default. It seemed to briefly solve it in my desktop view.
But not in my phone view. It’s also not showing the timezone lable. Arrgh!
I’ve reached out to Sites Community for support. We’ll see. It appears to be a common issue. For whatever reason embedding the code for a calendar works correctly, but the Sites gadget for Calendars doesn’t seem to adjust for daylight vs regular times. Odd little issue. Time sucker.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
