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

I believe I have discovered a daylight saving time bug (connectiq 1.1.3). It seems that when you get the info for a moment in order to display this, it displays it with respect to the current daylight saving time rather than the appropriate daylight saving time for the moment.

Take the following code which creates a moment based on the values specified given in UTC:

var m = Greg.moment({ :year => 2015, :month => 10, :day => 15, :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 => 2015, :month => 11, :day => 15, :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")]));

This outputs:

Oct 15 2015 15:00:00
Nov 15 2015 15:00:00

The first line is correct. I am based in the UK, currently in daylight saving time until Oct 25th, so when I give a time of 14:00 this is correctly displayed as 15:00 in localtime.

But the second line is incorrect. By then we are no longer in daylight saving time, so the time displayed should be 14:00:00.

Further confirmation of this bug is that if you use the Garmin Sun & Moon widget, and page down to Oct 25th, the times should jump by an hour due to the change of daylight savings. But they do not. The times from Oct 25 onwards are (for me) an hour out. They appear to be displayed assuming daylight saving is still in operation, when it is not.

It appears as if the Gregorian.info is outputting the time based on the current daylight savings rather than the appropriate daylight savings for the date we are getting information for.

Is this a known bug? How should I be reporting bugs? Should I email [email][email protected][/email]?

gasteropod over 8 years ago

Can anyone of the ConnectIQ folks comment on this? I'm sure it's a bug and would like it to be logged so it can be fixed. It will be hard to workaround I think.

What is the "official" way to report bugs?

Kyle.ConnectIQ over 8 years ago

Thanks for the report. I've filed a ticket and we'll investigate the issue. The best way to file bug reports is on the forums, that way everyone is aware of the issue. If you don't get a response in a couple of days, as in this case, feel free to bump the thread until we respond.

jim_m_58 over 8 years ago

Not sure how to determine if DST can be used/not used (other than for "today"), as the start and end days vary by location. In the US, it's always a Sunday at 2am, but the exact date changes year to year, and then there's Arizona and Hawaii that don't use DST at all.

Seems the watch would need a bunch of info to determine if past or future moments are during DST or not. For "today" I'm guessing there is a DST flag when a watch sets it's time using the mobile device. Even if the watch knew the "time zone" and "is DST used?", the dates for that TZ would need to be known for each year (past and future), for each TZ...

Looks like "today's" DST flag is used for all moments, and I'd guess the other option would be to make all moments other than today to be with DST=false. Either way it's up to an app to adjust for DST if needed based on what happens at your location.

(I live in AZ - and never have to change my clocks! This would be so much easier if others also stopped using DST. :) )

Here's the kind of info that would be needed, just for 2015...

http://www.timeanddate.com/time/dst/2015.html

gasteropod over 8 years ago

Looks like "today's" DST flag is used for all moments, and I'd guess the other option would be to make all moments other than today to be with DST=false. Either way it's up to an app to adjust for DST if needed based on what happens at your location.

I sincerely hope that is not the case Jim. The watch already knows the timezone and adjusts for localtime for every location and there is a framework in place for this timezone information to be regularly updated by Garmin as changes occur. The future and historic data required to calculate DST is very small due to the rules, less than 20Kb of data in the ascii tztab file on unix systems, and I expect the watch already has this loaded and kept up to date with the regular timezone file updates.

If an app had to do this it would require a mechanism such as JSON to keep this updated but this would be hard to store in the object store. Therefore, realistically the app would need to be updated every time there was a change. The app would also need to have the ability to determine the timezone for the location, duplicating something already done in the watch.

If Garmin were to decide that the Gregorian Info was going to be based on the current DST rather than the DST of the moment itself then I think this should be clearly documented. I'll wait for the official update from Garmin, but I expect in reality this is a bug.

jim_m_58 over 8 years ago

I don't think the watch knows the TZ. By default it gets the local time from the mobile device. The TZ config in GC is for Garmin Connect and it's display of data on the website and GCM app. That's why when you go to a different TZ, the time from the mobile is displayed on the watch for your current location, without changing anything in your garmin profile. There is a timezoneoffset on the watch (# of seconds), but not the actual TZ, and again probably comes from the phone.

The "time" from the phone probably also includes today's DST time flag.

I might be wrong...

gasteropod over 8 years ago

When I have changed timezones, all I need to do to get the watch to show the correct local time is to acquire satellites. This is without the watch being connected to the phone at the time. Therefore I think the watch knows the timezone from the position rather than getting it from the phone. This is the way other watches work too which do not have phone connection. I have always assumed that the "Time Zone Map" updates which are sent to the watches periodically are for keeping this information up to date.

jim_m_58 over 8 years ago

When I have changed timezones, all I need to do to get the watch to show the correct local time is to acquire satellites. This is without the watch being connected to the phone at the time. Therefore I think the watch knows the timezone from the position rather than getting it from the phone. This is the way other watches work too which do not have phone connection. I have always assumed that the "Time Zone Map" updates which are sent to the watches periodically are for keeping this information up to date.

This might be based on watch type.. The vivoactive doesn't use GPS to set the time, and I've never seen it get a "Time Zone Map"..

I had a FR15 that did use GPS to set the time, and the va is different. Could it be that CIQ is providing a consistent interface across devices, so it doesn't use something available on only some watches?

gasteropod over 8 years ago

I assumed all watches used GPS to update the time. All mine in the past have, but have never had access to the Vivoactive. I'm currently writing for the Fenix 3 which does get time zone map updates.

But, if not all watches have this and CIQ needs a consistent interface this could be a problem. Guess we need to wait for the official update from Garmin now then.

Really hope I do not have to implement this in the app. The reality is that if I do it would probably have to be a JSON service which will lookup the timezone for a given lat/long and then query the IANA timezone database for that timezone to get the historic and future dates for that timezone. I could do this every time the app location is explicitly set. Hopefully this would be small enough to store in the object store. But this is a whole lot more complex than I would want. In the short term I will probably put a caveat that the times displayed are relative to the current DST rather than that of the corresponding date. Although I might hard code in the UK since the date rules do not change very often and it would not be too difficult to code a single country.

cliv3run over 7 years ago

I believe I have discovered a daylight saving time bug (connectiq 1.1.3). It seems that when you get the info for a moment in order to display this, it displays it with respect to the current daylight saving time rather than the appropriate daylight saving time for the moment.

Take the following code which creates a moment based on the values specified given in UTC:

var m = Greg.moment({ :year => 2015, :month => 10, :day => 15, :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 => 2015, :month => 11, :day => 15, :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")]));

This outputs:

Oct 15 2015 15:00:00
Nov 15 2015 15:00:00

The first line is correct. I am based in the UK, currently in daylight saving time until Oct 25th, so when I give a time of 14:00 this is correctly displayed as 15:00 in localtime.

But the second line is incorrect. By then we are no longer in daylight saving time, so the time displayed should be 14:00:00.

Further confirmation of this bug is that if you use the Garmin Sun & Moon widget, and page down to Oct 25th, the times should jump by an hour due to the change of daylight savings. But they do not. The times from Oct 25 onwards are (for me) an hour out. They appear to be displayed assuming daylight saving is still in operation, when it is not.

It appears as if the Gregorian.info is outputting the time based on the current daylight savings rather than the appropriate daylight savings for the date we are getting information for.

Is this a known bug? How should I be reporting bugs? Should I email [email][email protected][/email]?

Hi,
running the same code today with ConnectIQ 2.2.3, but taking 2 actual dates:
March 1st 2017, 2pm and April 1st 2017, 2pm, with GPS coordinates around PARIS, the code works on emulator (1 hour difference between the 2 dates) but returns the same date on a fenix3 watch.
Same problem if you get the clockTime:
var clockTime = Sys.getClockTime();
var dstOffset = new Time.Duration(clockTime.dst);
var dst=dstOffset.value();

dst will be zero on watch and 3600 on emulator with PARIS GPS coordinates (daylight is set in Paris!).
Any idea what is wrong ?
thanks,

.dst

travis.vitek over 7 years ago

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.

Hi,
running the same code today with ConnectIQ 2.2.3, but taking 2 actual dates:
March 1st 2017, 2pm and April 1st 2017, 2pm, with GPS coordinates around PARIS, the code works on emulator (1 hour difference between the 2 dates) but returns the same date on a fenix3 watch.

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?

Same problem if you get the clockTime:
var clockTime = Sys.getClockTime(); var dstOffset = new Time.Duration(clockTime.dst); var dst=dstOffset.value();

dst will be zero on watch and 3600 on emulator with PARIS GPS coordinates (daylight is set in Paris!).
Any idea what is wrong ?

I'd expect Sys.getClockTime().dst to be 7200 (UTC+2) when run in Paris. 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