Open ykushch opened 7 years ago
Yes, this issue was discussed in https://github.com/mangstadt/biweekly/issues/76
My only suggestion is to try to use the "non-Outlook" versions of the files and see if they work.
Okay, I see. I requested to fix tzurl. And they've managed to update the site. Anyway, I think that we need some kind of fallback mechanism here for such cases as this site could not be the single source of truth 🙂
Nice, thanks for contacting them! 👍
One alternative would be to bundle the timezone definitions with biweekly. Getting them all downloaded would be tedious though.
Note that the website is only used when you are writing an iCal file and want to format your timestamps in a timezone other than UTC. It's possible to provide your own VTIMEZONE definition from a source of your own choosing. So, you could download the ones you need from tzurl.org and then use the downloaded files to generate iCals. I don't think it's possible to generate VTIMEZONE components on the fly from a pure Java TimeZone object.
You could also choose to use global IDs instead of VTIMEZONE components, but my impression is that they are not as widely supported.
I am thinking of bundling of this stuff. I will do a pr for this functionality. Basically, if we cannot download firstly, then we should warn that URL is not working/not reachable and then fallback to our bundled files. WDYT?
Sounds good. I think I would like to provide a separate method which retrieves the timezone definition from the bundled files. So, users can still call the download
method if they want to download them.
If you'll navigate to the tzurl then you won't find cities that was before. Maybe we need some fallback solution here.