You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Look into this, and possibly take over updating of ThreeTenABP.
Edit: Use case for SeriesGuide: release times might be defined for new time zones. On the other hand, it probably makes sense to stick to time zone data of the device to avoid issues when users use a removed time zone on their device. So using java.time + desugaring might still be an option.
Edit: with the new custom time feature which stores time zone it's more important that all devices support the same time zones. Or find a way to fall back to a more reasonable time zone (currently just always America/New_York).
Update 2024-12: since Android 10 these updates should be part of Google Play System updates (but only since Android 14 can partners no longer use the APK based update mechanism):
I am still making releases for tzdb updates for now. It's really easy.
Also note that you can bundle your own tzdb today and use the library by pointing it at yours. Although this has the downside of there being two embedded copies.
The best option for taking over, should it come to that, is to copy out the one class in the library, depend on the no-tzdb variant of ThreeTenBP directly, and embed the TZDB in assets. Not worth a whole fork.
UweTrottmann
changed the title
Take over updating ThreeTenABP to get latest time zone data?
Switch to built-in Time APIs once requiring Android 10
Dec 13, 2024
https://github.com/JakeWharton/ThreeTenABP/ development apparently is winding down and points to using the java.time APIs with Android Plugins' desugaring support.
However, AFAIK this means devices will not have access to the latest time zone data as these updates depend on the manufacturer? https://source.android.com/docs/core/permissions/timezone-rules
Look into this, and possibly take over updating of ThreeTenABP.
Edit: Use case for SeriesGuide: release times might be defined for new time zones. On the other hand, it probably makes sense to stick to time zone data of the device to avoid issues when users use a removed time zone on their device. So using java.time + desugaring might still be an option.
Edit: with the new custom time feature which stores time zone it's more important that all devices support the same time zones. Or find a way to fall back to a more reasonable time zone (currently just always America/New_York).
Update 2024-12: since Android 10 these updates should be part of Google Play System updates (but only since Android 14 can partners no longer use the APK based update mechanism):
So once minSdk is at that version, might consider switching.
The text was updated successfully, but these errors were encountered: