Thank you for the debug information. I have passed this on to the IA developers.
2 Likes
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
@BraunMincher I will send you a direct message > look at top right Avatar to find it > it will be a green envelope > it will be a private message channel with select members of the Scoutbook User Advisory Council (SUAC)
1 Like
I have the same issue - it still exists. (Glad to have found this post!)
â The old scoutbook calendar URLs are no longer supported and do not work.
â The newer Scoutbook Plus URL shows as four hours ahead.
Has the SUAC made any progress on updating the time zone embedded in the URLs, or is this on a roadmap for future implementation?
@MichaelWilliams14 - have you checked the time zone settings in scoutbook.scouting.org and advancements.scouting.org. Our calendar subscriptions show the correct time.
If this is related to godaddy, the issue is that their calendar is unable to properly handle the url. Goggle has no problem with it.
Just as a point of clarification, the SUAC folks are just volunteer scouters. They are not actually the ones who are doing the development.
Charlie - thanks, I meant whoever is managing the site, not SUAC.
Stephen - Understood. Timezones are set in both sites. Google does display the calendar correctly, but GoDaddy does not.
While therefore I suspect the issue is on Godaddyâs side, from BraunMichnerâs posts above, it sounds like the adv.scouting.org link was sharing as âzuluâ time. Not sure if this is still the case (and Google just interprets it differently) or if the issue truly is on Godaddyâs side.
@MichaelWilliams14 - well here is the thing⊠if google gets it right, then it is a godaddy issue.
Stephen - Maybe itâs a GoDaddy issue, maybe not. This wasnât an issue with the older SB links. It is now an issue with the new links.
The above poster (Braun) said the new events each have âZuluâ (GMT) time added to each eventsâ code. I suspect Google and iCal may be smart enough to change to the userâs time zone or something, which is why they work. GoDaddy leaves it at Zulu.
Who might be able to confirm if those are still in the code of each event, or whether that has been fixed? (Or is that correct formatting of an event?)
FYI for anyone else seeing this with similar issues⊠GoDaddy customer service wants us to upgrade ($180/year) our account so we can use the âAppointmentsâ feature to manage time zones. (The timezone is already correctly set to EST). What frustrates me is if the event code is right and Google/iCal read it correctly, it sounds like GoDaddyâs code must be âbreakingâ the code to change to GMT, then charging to fix the issue. (But perhaps I donât understand the technical side.) Regardless, I did not upgrade/pay to discover whether the upgrade works or not.
If anyone else has run up against this and found a solution, please post.
@MichaelWilliams14 - let me rephrase this for you⊠if all internet calendars can subscribe to the url and the times be correct EXCEPT for godaddy, what would that tell you. You would be better served by inserting thee google calendar in your site rather then rely on the godaddy version.
It works for google, Apple, and Microsoft. It is a GoDaddy issue.
1 Like
As the person who initially created this thread back at the beginning of the year, I will tell you that this whole âtime zoneâ display issue has caused much frustration and wasted time. Sadly, I am not surprised that so many others are having the same problem (several have emailed me directly), but I think we have all come to the same conclusion â while the previous (legacy) SB calendar links MADE ADJUSTMENTS to the local time zones (to set them to whatever the pack/troop/unit setup in the portal), the new (âIAâ) calendar links do NOT, and instead pass on the raw Zulu / GMC / UTC times to whatever program you are using to display them. EVERYONE except the great folks at GoDaddy (note: sarcasm) have logic that is smart enough to âfixâ this for the end users (when displayed), but GD does not, and so for all of us who are âbeholdenâ to them for our websites, we experience the same display problem documented above.
I am no longer an official pack leader (but was previously the Committee Chair), but one of the more âtechnically mindedâ of our pack implemented the following fix for us back in April, which works for the time being with the new IA feed (but, unfortunately, I do not have any further details or specifics to share of âhowâ exactly this was programmed):
Wrote a quick script and hosted it in Google cloud. When it receives a request from our events page it downloads the calendar from IA and adds the missing time zone info before serving it.
Yeah, this is certainly a shortcoming (IMHO) of GoDaddyâs inflexibility, but for all practical purposes, it seems that it would be best (easiest?) if the developers for the ânew and improvedâ Scoutbook could just deliver the new ICS files WITH the time zone ALREADY ADJUSTED to match the pack or troop local time settings (since they did this before just fineâŠ).
Sorry for everyone else who is experiencing this issue and hope that someone figures out a fix that can practically be applied to all units (that does not involve the behemoth of GoDaddy or other world powersâŠ). May the force be with you!
Braun Mincher
Erie, Colorado
1 Like
Google, Apple and Microsoft all properly translate UTC to the local userâs Time Zone. BSA IT will not be expending resources to implement a change to workaround GoDaddyâs issue.
GoDaddy will need to fix the issue or units will need to find an alternate platform to host a calendar subscribed to the Scoutbook Plus calendar.
2 Likes
Ahh⊠good luck with that. From a practical standpoint, I think everyone knows that is not going to happen. Yes, GoDaddy is deficient in their technology strategy here, but I would respectfully argue that BSA IT made this work BEFORE (in the legacy ICS links), but broke it (by not considering it) in the new version. Itâs tough to take away functionality that previously worked flawlessly for so many.
While we have a unique solution here for our individual unit (and I am but a lowly parent/volunteer, so take my response here with a grain of salt), practically and objectively speaking, the best overall solution here (least resources / most benefit to the masses) would certainly be for BSA IT to re-write the several lines of code (?) in the new calendar links that they took out of the old ones (and everything will work againâŠ). Considering how many units â across the country/globe â have long ago implemented the GoDaddy calendar display (via their website template), and the lack of technical resources generally available at the pack level, I am of the subjective opinion that the fix here lies with BSA IT (rather than GoDaddy).
BSA IT has told me they will NOT workaround GoDaddyâs issue. The calendar implementation is following the standard used by the major calendar vendors.
I am closing this thread because no amount of arguing will change the position.
1 Like
Braun - thanks so much. What a help/relief to just better understand what is causing the issue.
If the correct formatting of a calendar event doesnât include the timezone, I get why BSA wouldnât want to add it - could cause future issues/break other âcorrectâ things elsewhere. Your former unitâs solution (using a script to add the timezone info) makes sense. Iâll see if we have someone more technical who might be able to experiment with this, and in the off chance we do and figure something out, Iâll post what details/instructions I can here for anyone in a similar situation who stumbles across this post.
1 Like
