Clocks didn't flip over to BST?

Posted on
Page
of 2
/ 2
Next
  • Is it me (my app) or did none of the Clock Apps (in UK) switch over to BST. Haven't tried a satellite resync yet.

  • It is not implemented jet, would be a nice feature to have.

    Store flag if daylight saving is relevant or not in app Languages and use in clocks.

    Edit: My workaround is to increase timezone by one in Settings.

  • Ah ha... nice workaround :-)

  • I just reinstalled my default apps and it is now showing correct time. Hmm... what did I miss? I did try reboot earlier and syncing with GPS... maybe my code didn't use the GPS info correctly.

    Locale is showing TimeZone : 1 Don't really remember if it was 0 earlier.

  • Yepp, I increased the timezone by one (I'm at CET, that's +1 hour. Now it's set to +2 to show the current valid local time)

    AFAIK GPS is UTC, so no DST change there.

    DST is kind of crazy and weird, if you want to support all countries. So the best thing I think would be to expand the Locale loader and load your selected country's next couple DST change dates.

  • Well, those change dates can be formulated as rules like in the Olson tz database cf. eg. https://en.wikipedia.org/wiki/Tz_database#Daylight_saving_time_(DST)_rules, https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_rule_lines
    So it would be enough to include the current rule for a locale . Problem ist that a locale could contain lots of timezone (eg. the US is fragmented, going to conty level).
    So maybe a better idea would be a special settings app, which would read the current GPS location, query the current time zone info for this location and use this in the future.
    Google Maps has such a API cf https://developers.google.com/maps/documentation/timezone/intro .
    Unfortunatly nominatim dismissed including timezone info cf. https://trac.openstreetmap.org/ticket/4200 .
    Or instead of GPS simple let the user select a timezone.
    The "next couple DST change dates" could be taken from https://raw.githubusercontent.com/moment/moment-timezone/develop/data/unpacked/latest.json

  • Well, no need to care about timezone. AFAIK dst change is always +1 and -1.

    Timezone: Yes the way locale is implemented it would be easy to include timezones as well, add timezones.js, use %Z for replacement, use locale.tz and timezone selection.

    But a better place for timezones and dst setting would be during download of app Settings like Languages does.

    How does that sound?

  • @DerGuteWolf wasn't aware of that. That last link looks pretty useful.

    Since Bangle uses a browser, it already knows the timezone offset: just type new Date() in any browser console. It will have the tz offset of your computer. Change your system timezone to a different, and new Date() changes to a different tz as well. So in 99.99% I think there would be no need for GPS position. Pre-select the timezone based on browser's tz, but allow the user to change it. Maybe?
    But the code would have to figure out the DST change date. Haven't looked in detail, don't know if it's always unambiguous based on the browser's time zone.

    And to save flash, memory, and CPU cycles on the Bangle, I think actual calculation should be done in the browser, and only minimal data and logic should live on the Bangle.

  • As I understand it, if you click set time in the App Loader it'll set up the timezone correctly based on DST - but the watch won't set itself.

    Extending locale sounds like a great plan - but then somehow we've got to add some code that checks the locale settings to see what the timezone should be. I guess that could be added to the bootloader?

    At least now, we have 6 months to think of a good solution :)

  • @MaBe: I think you underestimate the complexities of international summer time rules. First for the southern hemisphere the changes should be otherway round. Second the change dates vary wildly. Third, not always 1 hour, there are also eg 2 hour changes.

    @AkosLukacs: I think we could extend the locale html page (using the file from the link for the data) to also offer a timezone selection preset with the browsers current timezome and include in the locale data the next few changeover dates with their offests and names (perhaps in the compact format also available there). We still need to figure how to do the actual change, I think we would need another js file which should be executed at start and contains a setTimeout to do the change on time. I would also include a function to return the current time name.

  • @MaBe: I think you underestimate the complexities of internation summer time rules. First for the southern hemisphere the changes should be otherway round. Second the change dates vary wildly. Third, not always 1 hour, there are also eg 2 hour changes.

    Wow, I definitely did, thanks for your clarification.

    I guess that could be added to the bootloader?

    First I thought firmware is a good place, so all devices can benefit from this, but why not bootloader, other board can have a bootloader too :) .

  • The time on my watch keeps switching back and forth an hour which is really confusing. In Locale Time Zone is set 2. I have not figured out yet what is causing this.
    I have GadgetBridge attached, but I already disabled the option to sync the time in the android app thinking that might be the cause.

  • Hmm - I guess gadgetbridge could be the issue... It's possible it is sending time update commands which keep changing the time zone?

  • Ah yes, it is definitely GadgetBridge. I switched GB off, then went to Set Time in Settings. It showed the correct time, long press BTN3 back to clock. Clock displays the correct time. Activate GB again, clock reset to an hour earlier on refresh.

    But I don't see any code in the GB widget that would set the time?

    EDIT: I think I know whats going on. As I said, I set the Time Zone on the Bangle to +2 to compensate for daylight saving but GB is sending the current time zone, so +1 (even though I disabled the setting for syncing the time in GB).

    EDIT 2: But the again GB should send the correct time with TZ +1. I'm confused...

  • Regarding setTimeout: alarm.js uses clearInterval(); (ie stopping all setTimeout/setInterval), I am not sure if this would mean that an alarm would stop a setTimeout for daylight change?

  • even though I disabled the setting for syncing the time in GB

    Hmm. Looks like this is a bug in the Bangle.js plugin for gadgetbridge then. It does it whenever it connects - I guess it needs to check Gadgetbridge settings: https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/devices/banglejs/BangleJSDeviceSupport.java#L237

    I am not sure if this would mean that an alarm would stop a setTimeout for daylight change?

    It would when active, but then as soon as you loaded a new app it'd be fine.

  • Looks like this is a bug in the Bangle.js plugin for gadgetbridge then. It does it whenever it connects

    If only someone could fix this and build a new version.... 8-)

  • I'll try and sort out a fix for Gadgetbridge. So it looks like there are three issues here:

    • Gadgetbridge is setting time regardless of what the setting is set to
    • Gadgetbridge doesn't update the timezone in settings
    • The timezone used by Gadgetbridge is different to that used by the web browser - I'm not entirely sure what to do here. I use Android's TimeZone.getDefault().getRawOffset(). Any thoughts on this?
  • So according to this: https://www.tutorialspoint.com/java/util/java_util_timezone.htm

    abstract int getRawOffset()
    This method returns the amount of time in milliseconds to add to UTC to get standard time in this time zone.

    So getRawOffset() should give (for my timezone) +1 right. But because of daylight saving it should be +2.

    So there is another method getDSTSaving()

    int getDSTSavings()
    This method returns the amount of time to be added to local standard time to get local wall clock time.

    Maybe a simple RawOffset+DSTSavings is enough?

    E.setTimeZone("+((TimeZone.getDefault().getRawOffset()+TimeZone.getDefault().getDSTSavings())/3600000)
    

    But despite that the first really helpful fix would be for GB not setting the time at all if disabled in GB settings.

  • @Gordon:

    I saw you just fixed the bug in GadgetBridge, very nice! Do you know when/how often they will build a new version?

  • Honestly I don't - I think it's very much up to them. I'm experimenting with maybe allowing Google Maps notifications through as well, so we can get proper navigation

  • Ok thanks. I built a debug version myself until an official release comes out and can confirm that it works.

  • About daylight savings: wouldn't it just be easiest to have a toggle in settings "Daylight savings: On/Off"? When enabled it just adds +1 hour to the current time.

    That way you won't have to mess with your time zone, which in turn breaks other stuff (like Gadgetbridge time sync)...

  • @Johan_O: Problem ist that not everywhere on the globe DST ist +1 hour

  • Are there enough countries that deviate from +1 for there to be a big problem? I've never looked closer at that particular detail.

    Shouldn't be too hard to implement a counter setting similar to what is already available for the time zone though.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Clocks didn't flip over to BST?

Posted by Avatar for PiOfThings @PiOfThings

Actions