• Replies 40 replies
  • Subscribers 23 subscribers
  • Views 7473 views
  • Users 0 members are here
Options
Related

TimeZoneOffset Question

DaveBrillhart
over 5 years ago

There are situations I've discovered where a Garmin device's Activity Elapsed Time is wrong. Seems to be a weird bug under some corner cases that involve hitting the lap button when stopped, or putting the activity to sleep then resuming it.

The more consistently accurate way to get an activity's elapsed time is to grab the difference between the current time and the start time.

TWO ISSUES with this:

1. activity spans the standard -vs- daylight savings time shift. I'm guessing the start time remains fixed, and the current time can shift +/- an hour.

2. activity crossing a timezone. Again, guessing the start time stays fixed in the starting TZ, and the current time shifts +/- an hour.

There is a timezoneoffset() function returned in seconds. anyone know if this function adjusts continuously across a particular timezone - shifting a few seconds every mile traveled east or west? or just at the TZ boundaries?

I think I'll just go with the system elapsed time and not try to code a complex work-around for a bug.

  • over 5 years ago in reply to jim_m_58

    I guess EPO/CPE are Garmin acronyms for the provision of Augmented GPS or A-GPS which would assist the device's GPS subsystem to get a first fix and so shortcut the 12.5 minutes required for receipt of the complete GPS almanac from the satellites which in turn would be required after a long period of inactivity or a wake-up in a new location distant from the last known location.

    It's not surprising that an old hand at GPS like Garmin would provide such a service, but it's nice to hear that it does. 

    I wonder what EPO/CPE actually stand for?



  • over 5 years ago in reply to Alan.raceQs

    EPO File Information

    Extended Prediction Orbit (EPO) files allow GPS devices to predict where satellites will be in the sky, which reduces GPS acquisition time. With updated EPO files on a device, instead taking 2-3 minutes to find GPS signals, it will usually take 5-10 seconds.

    EPO files expire, and are usually only good for a range of 3-14 days. In order to keep the EPO files updated, sync the device regularly.

    https://support.garmin.com/en-US/?faq=6IbaJEHc1i9gydzQomXzyA

    It's called CPE on the devices with the new GPS chipset.

    The status of EPO/CPE can be seen on the last page of "about" on many devices.

  • over 5 years ago in reply to jim_m_58

    Just so happened I had a device that hadn't gotten the latest time zone map, and here's what I see in Garmin Express (the change log)

  • over 5 years ago in reply to jim_m_58

    What a happy coincidence: finally some hard evidence of this elusive "Time Zone Map" !

    I wonder if there is a dedicated team deep in the bowels of Garmin HQ scanning the international media for news  geo-political changes to time zones, or maybe there is a subscription service that provides regular updates? 

    I don't see any change log in GE, I guess because I don't use GE to update my devices?

    I wonder how it would be deployed to my devices when updating via GCM or GCIQ?

    Was it a FW update that generated that change log?

    (so many question... sorry)



  • over 5 years ago in reply to Alan.raceQs

    As I've said the updates come out a couple times a year around the time that places start switch DST.  They are a "silent update" (like EPO/CPE), but you don't even see the last update in about.

    Like I said, I've seen them for years, and it just so happened I hadn't updated my car nav system since the last one, so I was able to get a screen shot.

  • over 5 years ago in reply to jim_m_58

    What car nav system do have that you update with GE? 

    jim_m_58 said:
    As I've said the updates come out a couple times a year around the time that places start switch DST.  They are a "silent update" (like EPO/CPE), but you don't even see the last update in about.

    What is a "silent update"? Is it something that happens in a sync to a device (via GCM), with no user interaction of approval or reporting?

  • over 5 years ago in reply to Alan.raceQs

    Nuvi 55.

    By "silent" I mean with some devices, you see a message when new FW is installed.  I've not seen that with tzmap.

  • over 5 years ago in reply to jim_m_58
    jim_m_58 said:
    Nuvi 55.

    Ah, it wouldn't have come to my attention as it only comes loaded with maps of "the lower 49 states" and Aussie maps would cost an extra $USD155.00

    jim_m_58 said:
    I've not seen that with tzmap.

    And that explains my ignorance. I only ever update with GCM, so would never have seen any of this and I haven't seen anything about it in the Garmin documentation.

    Thanks for your patience.

  • over 3 years ago

    Hi,

    Just for clarification for the timetoneoffset and dst and how they work:

    Currently I'm +2 hours ahead of UTC so the clocktime timezoneoffset returns 2 and dst returns 0. That's correct, but if we change back to +1 hours ahead of UTC in November, the offset will remain 2 and dst will be 1 or -1, or offset will change to 1 and dst will change in which direction?

    Thank you.

  • over 3 years ago in reply to DavidJenei

    TL;DR ClockTime.dst works in the sim, but not the real device, so you shouldn't use it. Luckily all you should need is timeZoneOffset for most uses.

    --

    ClockTime.timeZoneOffset is actually the offset from UTC in seconds (as per the docs). This is always the case regardless of whether DST is currently in effect or not.

    ClockTime.dst is your timezone's current DST offset in seconds - in other words, it's the difference between the normal zone offset and the current zone offset. When DST is not in effect, it should be zero. When DST is in effect, it should be 3600 (1 hour). Unfortunately, this isn't really documented.

    For example, I'm in Eastern Time, which is UTC-5 during non-DST and UTC-4 during DST (rn).

    If run the following code in the simulator...

            var myTime = System.getClockTime();
            System.println("dst = " + myTime.dst);
            System.println("timeZoneOffset = " + myTime.timeZoneOffset);

    ...I get the following output:

    dst = 3600
    timeZoneOffset = -14400

    Unfortunately, when I run similar code on a real device (simple data field on FR935)...

        function compute(info) {    
            var myTime = System.getClockTime(); // ClockTime object
            return myTime.dst + "|" + myTime.timeZoneOffset;

        }

    ...dst incorrectly has the value 0. I get the following output

    "0|-14400"

    https://forums.garmin.com/developer/connect-iq/f/discussion/127/sys-getclocktime-never-provides-a-value-for-dst

    It was mentioned over 7 years ago (!) that dst would probably be removed, but looks like that's not going to happen.

    travis.vitek said:
    The Sys.getClockTime() appears to correctly return time information for the local time zone, but it doesn't fill in the ClockTime.dst field as advertised.

    AlphaMonkeyC said:
    In preview 2 we are adding a field in ClockTimer named timeZoneOffset which gives the number of seconds from UTC the current time is. Long term I think we will probably remove the DST flag, as I'm not sure it adds a lot of utility.

    A couple of related bug reports:

    https://forums.garmin.com/developer/connect-iq/i/bug-reports/clockinfo-dst-is-0-on-the-watch-correct-value-on-the-simulator

    https://forums.garmin.com/developer/connect-iq/i/bug-reports/gregorian-info-handles-dst-incorrectly-for-dates-other-than-now-today-works-in-sim-not-on-device

    forums.garmin.com/.../docs-for-gregorian-moment-imply-that-the-input-is-in-local-time-gregorian-info-and-utcinfo-suggest-otherwise