How to get a Moment from a local time?

3960579 2 days ago

Trying to code a data field that will display different things depending on whether the current time is within a predefined interval each day.

For example, "Lunch" if it's between 1:00 pm and 2:00 pm, local time.

Couldn't find a preexisting thing that did that, so I figured I'd start from converting a string with a time (so that it's easier for me to enter later) to a Moment for that time today.

public function splitTime( timeString as Lang.String) as Time.Moment {
    var sep = timeString.find(":");
    var hour = timeString.substring(0, sep).toNumber();
    var min = timeString.substring(sep + 1, null).toNumber();
    return Gregorian.moment( {:hour => hour, :minute => min} );
}

Problem is that gives me the time I entered in UTC.

How would I take a local time (like 13:00) and get a moment that represents that time, today, in the local timezone?

Top Replies

All Replies

0 7677473 1 day ago

developer.garmin.com/.../Gregorian.html

0 7677473 1 day ago in reply to 7677473

use localMoment instead of moment

0 3960579 1 day ago in reply to 7677473

localMoment needs a position though. Is that stored somewhere?

0 flowstate 1 day ago

You can't really go from a local time to a Moment, unless you have coordinates so you can use localMoment / LocalMoment. Yeah, there are things you can do to get the TZ offset for your current location, but they aren't perfect for any case other than now (this exact instant):

- for days other than today (actually, instants other than now), you can conceivably determine the TZ offset by using Gregorian.info() and Gregorian.utcInfo() on the same Moment.

Unfortunately, older devices have a bug in Gregorian.info(), where it's impossible to get the correct TZ offset if the day you're asking about has a different offset than today, due to TZ rules.

e.g. Say I live in New York, and it's currently December 2025. Today's DST offset would be -5 hours (DST would not be in effect). On older watches, if I use Gregorian.info to ask for the local time for some Moment in June 2026, it would incorrectly apply an offset of -5 hours (which applies to "today" - i.e. December 2025), instead of the current offset of -4 for June 2026 (because DST would be in effect).

- you can reliably get the TZ offset for this current instant, but there may still be edge cases that will be difficult to handle around the DST transition time, if you need to deal with times that occur today, but aren't this current instant. (You can't just naively add the TZ offset for "now" to any given time during the current day and expect it to be correct.)

+1 flowstate 1 day ago in reply to flowstate

What I would do, given the limitations of the API, is

1) if I need to compare a local time (like Nov 11, 2:05 PM 2025) to a moment (such as Time.now()), I would do the opposite conversion - convert the Moment to local time using Gregorian.info() and compare the individual components that are returned (year, month, day, hour, minute, and second)

0 flowstate 1 day ago in reply to flowstate

2) if I need to *store* a local time (in storage or memory), there are a few options:

2a) store the broken down local time components (e.g. year, month, day, etc)

2b) store local time by converting it to a Moment as if it was UTC time - using Gregorian.moment() - and saving that Moment. Ofc when you read that Moment back, you will never use it directly, but instead first convert it back to broken-down local time using Gregorian.utcInfo().

Ofc 1) / 2a) / 2b) only work if you are working with local time *without reference to any specific time zone*, but only assuming that "local" means "wherever you happen to be at the moment" [*]. Ofc if you have a specific position in mind, you would be able to use LocalMoment after all.

[*] one obvious use case for working with local time (but no specific time zone) would be an alarm. e.g. If I want to wake up at 7 AM local time, it doesn't matter what the actual time zone is.

If you actually need to refer to local time in specific time zone(s), it would probably be best to actually ID the zone by position and use LocalMoment (so you get the proper TZ offset and DST rules). It's too bad CIQ doesn't give us access to its TZDB, so if you wanted to give your user a list of zones to choose from, you'd have to hardcode them yourself (e.g. list of place names with associated coordinates.)

0 3960579 1 day ago in reply to flowstate

Ah that's a good idea! Yeah I basically just need local time wherever I happen to be at the moment (preferably without having to rely on stuff like GPS) so 1) and 2) work great.

0 flocsy🤠 1 day ago

Another approach could be to convert everything to string in 24h time format and store the settings that way and compare these strings to decide if you are before, inside or after a time period. "1300", "1400"