Time.today() timezone vs simulator timezone

flocsy🤠 said:

but the midnight was at a different time depending on the timezone, shouldn't today() return a LocalMoment?

Maybe, but LocalMoment was introduced in CIQ 3.3.0 and Time.today() has been available since CIQ 1.0.0.

One could also ask why there's no variant of Time.now() that returns a LocalMoment, or why an arbitrary Moment can't be converted to a LocalMoment unless you know your exact location.

(To be clear I'm saying it would be nice if there was some sort of function to get a LocalMoment for your current location or TZ)

[1/x]

flocsy🤠 said:

Or does it return the "UTC Moment" of midnight in the "current" timezone of the device?

You could always test this for yourself.

I just called it in the simulator, and that's indeed what it does.

System.println(Time.today().value()); // prints "1746849600"

This is midnight [beginning of the day] in my local timezone [UTC-4]

Looks like your intuition was correct that the concept of midnight [beginning of day] is really only useful for the local timezone. I don't really think "UTC Moment" or "current" need scare quotes here tho. The Moment class does represent time in terms of UTC, midnight does make sense in the current timezone, and the concept of a current timezone does make sense for your device.

Nobody cares too much when it was midnight in UTC, since that's not even actually a timezone, and UTC+0 only corresponds to a physical place for half of the year.

Also, any local time can be represented as UTC, so I don't think it's too much of a stretch to represent midnight local time as UTC.

[2/x]

I think the documentation also reflects this behaviour [although perhaps it isn't clear at first glance]

631087200 is Sun Dec 31 1989 00:00:00 GMT-0600 [Central Standard Time]


If I were in charge of writing the docs, I probably would:

- clarify that "midnight" here means "beginning of day" [technically every day has two midnights]

- clarify that CST is UTC-6 / GMT-6

- convert 631087200 for the reader instead of making them convert it themselves

[3/4]

flocsy🤠 said:

is there a way to set the timezone of the simulator or it always uses the timezone of the OS?

The simulator uses the OS timezone. No different than your browser or any other app on your computer.

You should be able to temporarily change the timezone without even affecting the normal operation of your computer, since for most intents and purposes, the timezone and local time only affect what's displayed to the end user, and what's really important is UTC time. [Yeah yeah there are exceptions, like scheduling an event on a calendar, etc.]

I verified that changing the timezone on my computer affects the value of Time.today(). I did have to restart the sim after changing the timezone, which makes sense to me.

[4/4]

Also using 31 December as an example makes it even more confusing. I bet some think that probably the midnight here means the moment when people open the champagne bottles between the old and the new year. Any random date would have been better...

flocsy🤠 said:

Also using 31 December as an example makes it even more confusing. I bet some think that probably the midnight here means the moment when people open the champagne bottles between the old and the new year.

I think I already covered this:

FlowState said:

- clarify that "midnight" here means "beginning of day" [technically every day has two midnights]

flocsy🤠 said:

Any random date would have been better...

It might be intentional though, because if you actually convert the returned value in the example, you'll see that the output year is the same as the input year, which reinforces the fact that it's midnight (beginning of day), not midnight (end of day).

Again, one problem is that Garmin doesn't tell you what the returned value in the example corresponds to, but instead expects the dev to convert it themselves.

Instead of simply writing:

// UNIX epoch 631087200

They should've wrote something like:

// UNIX epoch 631087200 - December 31, 1989 12:00 am CST (UTC-6)

However, I'm gonna guess that the reason December 31, 1989 was chosen because the Garmin epoch starts on that date at midnight (UTC). (Midnight as in beginning of day)