Handling of DST Time Changes

[mruss77]

Infinitime does not seem to handle DST clock changes.

I set my phone's date/time to a few minutes before the beginning of DST, when one hour is skipped, and pushed a Set Time message via Gadgetbridge. The phone went from 1:59 to 3:00 AM (skipping the hour correctly), but the PineTime went to 2:00 AM. It remained one hour behind the phone for about an hour and 15 minutes. I'm not sure what ultimately corrected it, but it was eventually fixed.

Should GadgetBridge be notifying the watch when the clock changes for DST? The Bluetooth Current Time Service spec seems to say that servers should notify clients of a change in DST offset. Maybe this is simply a GadgetBridge problem.

At the end of the day, PineTime is a watch... should it natively handle DST clock changes without relying on a companion app? Unfortunately DST rules are complex with many variations around the world that are subject to change.

My main concern is that the alarm should handle DST changes and not go off an hour late or early.

[schneidr]

This should also be checked when one enters a different time zone. I didn't think of checking how/if that is handled when I was traveling earlier.

[mruss77]

Having dug into it a bit, InfiniTime doesn't get time zone information from the companion device. Whenever the local time is updated on the phone - could be a DST clock change, moving to a different time zone, or a manual clock change - eventually a "set time" message will be sent over Bluetooth, and the PineTime will pick up the new time. I guess when this happens would depend on the app you're using (Gadgetbridge, etc.).

As long as the watch picks up correct time from another device, we should be able to make the alarms work. I think if we wanted to handle DST clock changes natively, we'd have to build that into InfiniTime, because it looks like FreeRTOS doesn't natively support DST. It is probably easier to look at making sure we reliably get time changes from the companion device.

[sirnewton01]

I can confirm that the watch did not handle switching from DST to standard time. I had to manually sync with the companion app.

[geekbozu]

Correct we do not interpret Timezones or DST at all, it is up to the companion apps to force a re-sync of the clock currently when a timezone/DST event occurs.

[evergreen22]

I've crossed time zones several times recently and can confirm that the watch DOES update correctly when paired with GB. As @mruss77 noted, GB sends a notification whenever the time changes. IMO this is best handled in the companion app.

[Itai-Nelken]

A button in the 'Set time' setting that turns DST on/off (skips forward/backwards one hour) would be nice. my Casio "Dumb" watch has that and it's a nice way to change quickly the evening before the change without having to change the time manually and potentially accidentally setting incorrect time.

[sirnewton01]

Do we expect that with the new set date/time feature that the watches must be constantly tethered to a mobile device in order to keep themselves in sync with the actual time? Or are the watches meant to be independent smart time keeping devices?

I think my expectation is that they would function independently and be smart enough to handle daylight savings time switches, unlike the clock on my stove. I don't always have my phone near enough to my watch to be assured that the sync will happen. Siglo in its current form doesn't seem to remember to keep paired with my watch either.

[Avamander]

Do we expect that with the new set date/time feature that the watches must be constantly tethered to a mobile device in order to keep themselves in sync with the actual time?

Yes. Constantly twice a year.

Or are the watches meant to be independent smart time keeping devices?

Very frankly, if you only want independent timekeeping then you should buy a watch. A regular watch that is designed to be standalone will provide that functionality. Different design goals yield differing features and trade-offs. See also: bike and electrical bike.

[sirnewton01]

If the watches are not truly independent smart time-keeping devices then I think there needs to be some focus on automated and reliable tethering. I personally never see my watch auto-sync with Siglo. It's entirely manual from what I've experienced. If it were fully automated then DST wouldn't be a problem at all.

I know that DST is a super pain to implement and also there's some fundamental question about what purpose DST serves at all, but a significant number of places have adopted it for better or worse.

[Avamander]

Issues with Siglo are up to Siglo to solve.

[geekbozu]

We have been actively working on getting bonding and pairing working to persist connections and just general BLE improvements for months now.

Out side of this companion app implementations are well companion app implementations. Please raise your issues with them.

[Avamander]

To sum it up, the complexity of being and becoming timezone-aware is not worth it given the alternative solutions available. As @geekbozu said, effort has and will continue to be put into the latter. In addition to this current topic, the alternative approaches provide an overall better end-result.

I think this has been discussed enough for now and the focus won't change any time soon.

[sirnewton01]

The work that you've all been doing with infinitime is fantastic and thank you very much for that.

It is now clear (to me at least) that infinitime is not standalone and must have a companion app on a mobile phone to work correctly in the way that a smart watch is expected.

I think that this fact could be stressed on the intro page for this project so that others are aware as they begin to use their watches and don't raise bugs like this one. Also, it seems that some companion apps are working better than others. It might be helpful to highlight the combinations that are working better than others, such as Siglo, which seems to have some problems with the bonding despite the best efforts here.

[Avamander]

@sirnewton01

I think that this fact could be stressed on the intro page for this project so that others are aware as they begin to use their watches and don't raise bugs like this one.

The getting started guide, that is the first link in the readme file, does contain that information about DST.

It is now clear (to me at least) that infinitime is not standalone and must have a companion app on a mobile phone to work correctly in the way that a smart watch is expected.

I think you'll find that to be true about all smartwatches.

It might be helpful to highlight the combinations that are working better than others

Determining that information is time-consuming, ephemeral, not in the scope of InfiniTime and also discouraging to the companion developers that do not get picked.

[JF002]

It is now clear (to me at least) that infinitime is not standalone and must have a companion app on a mobile phone to work correctly in the way that a smart watch is expected.

This is a perfectly valid opinion, and it looks like your definition of "standalone" is more strict than mine.
In my mind InfiniTime can be standalone, as long as you manually set the time when switch timezone, winter/summer time and every now and then, because the clock of the PineTime will inevitably drift from the atomic time. This is exactly what I'm doing with my good old mechanical watch for years (which does not handle 30/31 days per months and leap years either).

Anyway, I agree that DST/timezone support would be a nice feature, but a much complex one. Contributions are welcome, as always :)
I don't think this feature request is invalid, and there's nothing wrong to ask for it. But don't forget we already have a lot of features we would like to add in the project, and so little time to actually implement them. It might take some time until someone decides to work on it.

Regarding the documentation, sure, it needs some love, and work is currently being done here for example. However, writing good documentation is a difficult task, and writing documentation where everyone easily finds any information they need is a huge task which requires great writing skills we might not have yet in the project. Again, if you think you can help on that topic, please, feel free to contribute! I'm sure, for example, that many users would be interested in a quick and up-to-date overview of each companion app and in a table that compares the features of those apps, for example.

The work that you've all been doing with infinitime is fantastic and thank you very much for that.

Thank you! We all appreciate those kind words :)

[sirnewton01]

The getting started guide, that is the first link in the readme file, does contain that information about DST.

This seems a bit buried and it's not what I suggested.

I think you'll find that to be true about all smartwatches.

Counter point: my children's Garmin smart watches required the companion app only for initial setup. They correctly adjusted for DST. None of them have a smart phone at the moment to run the companion app and keep their watches in sync.

Determining that information is time-consuming, ephemeral, not in the scope of InfiniTime and also discouraging to the companion developers that do not get picked.

If bonding and synchronization is required for correct operation of Infinitime then this does seem to be in scope because there is a dependency there. There's already a list, so it is already ephemeral, and already discouraging (maybe) to the companion developers apps that are a PR away from being listed. If the bug with the automatic time sync is in Siglo, as stated earlier, then it could be pointed it out so that a diligent user could try and help code up a solution, but they can also be made aware that it's not the ideal integration at the moment that can be relied on before purchase.

[Avamander]

@sirnewton01

Counter point: my children's Garmin smart watches required the companion app only for initial setup.

The concept of smartwatch really extends beyond the initial setup. An one-time synchronization doesn't really make a smartwatch, I have an alarm clock like that, it is not smart.

Generally I don't think it's up for InfiniTime or its documentation to explain what's the difference between a watch (with optional extra features) and a smartwatch. The reliance on external data providers for a large majority of functionality is inherit to all smartwatches, it is fairly obvious that is the case here as well.

This seems a bit buried and it's not what I suggested.

The old saying "You can lead a horse to water but you can't make it drink" applies here.

There's already a list, so it is already ephemeral

No, not really.

[sirnewton01]

Anyway, I agree that DST/timezone support would be a nice feature, but a much complex one. Contributions are welcome, as always :)

I know from previous experience that supporting DST correctly is very difficult and so I can only imagine what it's like to do it on a watch. Also, I've been involved in OSS development before so I know how much of a challenge that can be as well and keeping documentation up to date. Unfortunately, I can only offer my testing and feedback at this time. I hope that is useful to you and others involved in the project. If not, I can refrain from participating in issues in the future.

Thanks again for all your efforts.