Toybox::Time::Gregorian::Info daylight saving time bug?

According to timeanddate.com, standard time in Paris is UTC+1 (3600), daylight time is UTC+2 (7200), and daylight time runs from 3/26 @ 2am to 10/29 @ 3am.


It isn't clear to me exactly what you're saying here. Are you saying that if you write this code...

var m = Greg.moment({ :year => 2017, :month => 3, :day => 1, :hour => 14, :minute => 0, :second => 0 });
var i = Greg.info(m, Time.FORMAT_MEDIUM);
Sys.println(Lang.format("$1$ $2$ $3$ $4$:$5$:$6$", [i.month, i.day, i.year, i.hour.format("%02d"), i.min.format("%02d"), i.sec.format("%02d")]));

m = Greg.moment({ :year => 2017, :month => 4, :day => 1, :hour => 14, :minute => 0, :second => 0 });
i = Greg.info(m, Time.FORMAT_MEDIUM);
Sys.println(Lang.format("$1$ $2$ $3$ $4$:$5$:$6$", [i.month, i.day, i.year, i.hour.format("%02d"), i.min.format("%02d"), i.sec.format("%02d")]));


The resulting output shows the same date, but only an hour difference when run on a device? Given that there are 31 days between 3/1 and 4/1, and there is a transition from standard time to daylight time, I'd expect that code to produce

Mar 1, 2017 15:00:00
Apr 1, 2017 16:00:00


What do you get?



I'd expect Sys.getClockTime().dst to be 7200 (UTC+2) when run in Paris during daylight saving time. If you are getting 0 on a device, something wonky is going on. If you are seeing 3600, I'm thinking that the problem could be related to out-of-date time zone tables. Are you sure that your device has the latest time zone information?

Travis

Also, it seems tzmap on a real devices is used to determine the TZ offset for you and for today, when setting the time on the watch.

Now the sim. That is odd for anything involving DST. For example, I live in US MT, but in AZ, where we don't do DST. But while the rest of MT is observing DST, the time I see in the sim is an hour fast (I admit, I've headed out for lunch an hour early more than once! :) )

Seems to me, last time I looked into it on the sim and watch, in one case the TZ offset stayed the same, but the DST offset changed, and on the other, the TZ offset changed, but DST offset stayed the same (always zero).

If your goal is to find the difference in actual time between two date/times, where DST may or may not be involved, I think value() may be useful.
(untested with mc but should work!)

value() gives you the "unix time" (number of seconds since the unix epoc - midnight, Jan 1,1970), and doesn't know or care about DST.

So if you have "now" being the value() for today, and "then" being the value() of that date/time,

"now-then=diff" would be the number of seconds between the two. Then it's simple to convert that to days:hours:minutes:seconds.

As I said on either the sim or the watch, IIRC, I saw DST adjust being zero, but TZ offset changing. It might be worth checking that.

You can check for updates with Garmin Express. I also like to use WebUpdater sometimes because it lists out all of the individual "additional" updates, like time zone map, language updates, etc.

What is the timeZoneOffset? It's in Sys.getClockTime, along with dst. It might have changed when DST started while dst stayed 0.

You could try setting the date/time on the watch before DST started and see what timeZoneOffset and dst was then.

the UTC I'm talking about is timeZoneOffset, so timeZoneOffset from watch says 7200 since DST active.
How do you change the date of the watch ? There is no menu to do that !