UNIX Time after next Clock Change (CET to CEST) Issue?

In one of my apps I've a problem to understand Toybox.Time (incl. Gregorian). To explain I set up a simple data field. As an example I tried to execute with two UNIX times:
1554026400 should be 03/31/2019 @ 10:00am (UTC) -> 31.3.2019 12:00 (CEST)
1553940000 should be 03/30/2019 @ 10:00am (UTC) -> 30.3.2019 11:00 (CET)

using Toybox.WatchUi;
using Toybox.Application as App;
using Toybox.Time;
using Toybox.Time.Gregorian as Calendar;

class DataFieldTestView extends WatchUi.SimpleDataField {

    function initialize() {
        SimpleDataField.initialize();
        label = "Time Test";
    }

    function compute(info) {
        var time = 1554026400; // 03/31/2019 @ 10:00am (UTC) -> 31.3.2019  12:00 (CEST)
//        var time = 1553940000; // 03/30/2019 @ 10:00am (UTC) -> 30.3.2019  11:00 (CET)
        var nextDate = Calendar.info(new Time.Moment(time), Time.FORMAT_SHORT);
        var dateString = Lang.format(
            "$1$.$2$.$3$  $4$:$5$",
            [
                nextDate.day,
                nextDate.month,
                nextDate.year,
                nextDate.hour,
                nextDate.min.format("%02d")
            ]
        );
        return dateString;
    }
}

If I run both examples on Simulator, everything works perfect, data field presents the expected values:
1554026400 31.3.2019 12:00
1553940000 30.3.2019 11:00

Running on the device the result is:
1554026400 31.3.2019 11:00
1553940000 30.3.2019 11:00

Looks like the device is not considering clock change in the future and takes current time zone. Is this correct? Or am I thinking wrong. Is there any workaround?

My FR645M setting is time setup = auto

jim_m_58 over 6 years ago

This is something that's tricky, as 24hrs from Mar 30 11:00 is Mar 31:11:00 looking at it from today. I'm guessing where you are the DST shift happens between Mar 30 and March 31. But the watch uses "today" for this so it's 11:00. There is a flag for when the DST change has occurred, but again, it's from today's perspective, not the date or location, so things don't adjust for DST in the US if you are in Europe based on that flag for example.

Your app could contain data on when the DST shift occurs and use that, but that does change year to year, and you'd really need the same data for other locations (us vs Europe for example).. Even then what about dates last year?

But there's more. Consider EST in the US - it's UTC-5 but changes to UTC-4 And, DST may not change in all utc-5 places at the same time. I happen to live in US MST (UTC-7), and it's a place where we never change the clocks. So part of the year we are the same time in Denver, and part of the year, the same time as Los Angeles.

This is something where you may not want to trust the sim. For me, I'm now in a period where the time in the sim is actually 1hr ahead of the time on my computer, as we don't do DST. It knows DST based on some JVA stuff, and not what the watch knows.

So, the perspective on time is "today" and your specific location. How to handle that, really depends on what your app is doing/showing

FlowState over 6 years ago

IMO, UTC should be unambiguously convertible to local time (but not always vice versa), provided you know your time zone and DST rules.

My educated guess is that the watch does not have enough storage for the TZ database, so all conversions are done based on the current TZ. Having worked with this stuff before, the complete set of rules (including past rules) is pretty big, although the list of current rules isn’t so bad.

IMO, it would be nice if the OS would at least sync the current rule for your current TZ, given that it’s unlikely to change very often. And if it does change, then you need to sync anyway, to get the correct TZ on the watch. That would cover everything except historical dates and times (and future dates when we know that the rules will change.)

If I were you I would submit a bug report for this, in the bug reports forum. I can’t think of a workaround unless you use a 3rd party service or if you encode all the current rules in your app. The latter might not be feasible unless you also ask the user to select a time zone manually, which is probably not desirable.

forandy over 6 years ago

Many thanks for feedback. Because in my app it's only an issue max 2 weeks before DST (and hopefully next year DST is cancelled forever) I decide to keep it and inform user about deviation the days before DST :)