How do I determine local time in another timezone?

Luc over 1 year ago

I want to display a 2nd timezone and I can use Gregorian.localMoment but that takes in a time. What would be the code to get the correct local time including DST?

I could use localMoment but that requires passing in local time for that timezone but I only have the current local time:

// EXAMPLE AMS (+1 or +2 for DST)
var where = new Position.Location({
:latitude => 52.4,
:longitude => 4.9,
:format => :degrees,
});


var tz = Gregorian.localMoment(where, Time.now()).getOffset()/3600;
var info = Gregorian.info(tz, Time.FORMAT_SHORT);

// THIS WILL NOT WORK SINCE Time.now() is local time.

I'm guessing you would first have to figure out delta in timezones and then offset that perhaps?

Top Replies

Luc over 1 year ago +1

I think this works but let me know if that is correct:

  var where = new Position.Location({
    :latitude  => 52.4,
    :longitude => 4.9,
    :format    => :degrees,
  });
  var info = Gregorian…

All Replies

Luc over 1 year ago

I think this works but let me know if that is correct:

  var where = new Position.Location({
    :latitude  => 52.4,
    :longitude => 4.9,
    :format    => :degrees,
  });
  var info = Gregorian.info(Gregorian.localMoment(where, Time.now()),Time.FORMAT_SHORT);

FlowState over 1 year ago in reply to Luc

Yep that looks good to me.

To clarify some things which you wrote in your original post (for the benefit of others reading - I'm sure you've already figured all of this stuff out based on your reply):

- It's not the case the Time.now() is "local time". It's just the current time, expressed in a timezone-agnostic manner (UTC).

Time.now() returns a Moment, whose internal representation is the number of seconds since the Unix epoch (midnight Jan 1, 1970 UTC). UTC is chosen on purpose because these values are supposed to be timezone-agnostic (all timezones and daylight-saving time rules are defined in terms of UTC).

- What actually gives you local time (for your current time zone) is passing in a Moment to Gregorian.info(). If you wanted the same info expressed in terms of UTC, you'd use Gregorian.utcInfo().

- As you've found, Gregorian.info() also accepts a LocalMoment for when you want local time in a different time zone

Luc said:
I'm guessing you would first have to figure out delta in timezones and then offset that perhaps?

On a side note, given that LocalMoment is only available for devices which support CIQ 3.3.0 and higher (so very old devices are excluded), you may be wondering how to tackle this problem without LocalMoment.

The problem with trying to do this without LocalMoment is that there's no other way to tell whether DST is active in another time zone or not.

Given that LocalMoment isn't available for very old devices (below CIQ 3.3), your options there would be limited. What people usually do is allow people to enter or a select a TZ offset and provide a DST checkbox for the user to set manually. (The user has to know if DST is active or not, and they have to change the setting manually at every changeover.)

A different way to do it would be to define your own set of TZ/DST rules for each time zone you wanted to support. This would actually work, but:

- it would be tedious to convert some subset of the standard TZDB rules into another format for your own use (I've done it before, for an embedded device)

- you'd be responsible for updating the rules yourself, since they change in the real world

Luc over 1 year ago in reply to FlowState

Thanks for the explanation! Got it.

I show "DST" and have that working correctly by using localMoment (caching last known location from various API's) and fortunately don't need support for older watches.

FlowState over 1 year ago in reply to Luc

No problem!

Just so you know, there are a few known bugs for non-LocalMoment related TZ stuff. Shouldn't directly affect you, but just so you're aware.

- Garmin's DST logic for dates other than today (in the local time zone) is broken. i.e. If you ask for local time 6 months from now or 6 months ago, Garmin would apply today's DST logic, which means the answer could be wrong. forums.garmin.com/.../gregorian-info-handles-dst-incorrectly-for-dates-other-than-now-today-works-in-sim-not-on-device

- Another bug is that ClockTime.dst is always 0. forums.garmin.com/.../clockinfo-dst-is-0-on-the-watch-correct-value-on-the-simulator

Those 2 bugs combined meant that prior to LocalMoment, you couldn't even tell whether DST is currently active in your own time zone.

Luc over 1 year ago in reply to FlowState

Yes the 2nd bug I've hit as well and resolved through the forums (on top of that the SDK non-working example also has errors). Fortunately don't need different dates.