Unit and timezone handling

[bjorkert]

Summary of Changes:

This Pull Request introduces two main changes:

1. Use Units from the Profile Store Instead of the Top-Level Units

   • Description:

     • The units used within the profile's store (store.units) can differ from the units specified at the main level (profileData.units) when using Loop.
     • Since the units are primarily used for interpreting profile data (e.g., basal rates, carb ratios), it makes sense to prioritize the units specified within the profile store.
     • This change modifies the code to use the units from the profile's default store (store.units) when loading profile data.

   • Implementation Details:

     • Updated the loadProfile function to source self.units from store.units instead of profileData.units.
     • Added the units property to the NSProfile.Store struct to facilitate this change.

   • Future Considerations:

     • In the future, we may need to handle scenarios where both units are relevant.

2. Time Zone Support for Profile Data Based on Looper's Time Zone

   • Description:

     • When the looper is in a different time zone than the LoopFollow user, it's important to use the looper's time zone for accurate schedule-based setting displays (e.g., carb ratio, target range, basal rates).
     • This change updates the code to use the time zone specified in the profile (store.timezone) when determining the current profile data.

   • Implementation Details:

     • Modified the getCurrentValue function to use the profile's time zone instead of the device's local time.
     • Implemented a helper function getTimeZone(from:) to handle various time zone formats and parse them into TimeZone objects.
     • Cached the parsed TimeZone object in the ProfileManager to avoid re-evaluating it on each call, improving performance.

   • Time Zone Format Handling:

     • The code now supports different time zone formats, such as "Europe/Stockholm" and "Etc/GMT-2".
     • Adjusted casing and parsing logic to handle variations like "ETC/GMT-2" by normalizing them to standard IANA time zone identifiers.

Thanks to Odd Stoltenberg for reporting these two issues.

[marionbarker]

Status

Success. Tested with a schedule for target range. The new code reports the scheduled value based on Looper's phone not the LoopFollow phone.

Configuration:

• set up real looping phone with a different target range every 2 hours (saved as a Test Only Many Ranges profile)
• build LoopFollow on a test phone and view the URL for my real loop phone
• because it is a test phone, I can modify the time zone on the LoopFollow phone
• note - quit and restart LoopFollow after each time change

Test

LoopFollow main, version 2.2.6

• Timezone same as Loop phone, target displayed by LoopFollow matched value on Loop phone (98, 98)
• Timezone offset on LoopFollow phone from Loop phone (use timezones not manual time change)
  • if time is behind, (set to Honolulu instead of Cupertino): LoopFollow 94, Loop phone 98
  • if time is ahead, (set to Stockholm instead of Cupertino): LoopFollow 104, Loop phone 98

LoopFollow units_and_timezone

• Timezone offset on LoopFollow phone from Loop phone (use timezones not manual time change)
  • if time is ahead, (set to Stockholm instead of Cupertino): LoopFollow 98, Loop phone 98
  • if time is behind, (set to Honolulu instead of Cupertino): LoopFollow 98, Loop phone 98
• Timezone same as Loop phone, target displayed by LoopFollow matched value on Loop phone (98, 98)