Any way to use local time for the "Connection Lost" time?

[FirbyKirby]

The lost connection feature of the NetStatus appliance is really great. It's actually my main reason for deploying this project (I've got family who lives rural and they lose internet intermittently, which is annoying.) However, I noticed that the "Last online at XX:XX AM/PM" message on the connection lost screen is showing the UTC time.

Is there any way to use local time instead? For example, rather than 3:12 AM (UTC,) show 10:12 PM (CDT) if the timezone is properly set to America/Chicago (central daylight time.)

I've SSHed into the container and confirmed the timezone is set properly (using TZ environment variable.) here's the date command output.

/ # date
Tue Apr 27 22:24:24 CDT 2021
/ # 

I'm using Balena to deploy and manage the container. It uses a separate container for the browser, so I theorized that maybe the issue was in that container, but SSHing into that container gives the same result (date command shows local time without issue.)

root@1269b11:/usr/src/app# date
Tue Apr 27 22:27:03 CDT 2021
root@1269b11:/usr/src/app# 

Any thoughts?

[FirbyKirby]

Interestingly, when I connect with the SSH server on NetStatus container from my development machine over the network and use my browser to render the page, I think the local time is shown, not UTC (I'm having a hard replicating this since I need to disconnect from the network to get the "connection lost" page to show up.) Could this be related to a chromium setting? I've confirmed the Balena browser container has a properly set timezone and is providing local time using the date command at the terminal. So maybe something is specifically happening to the Chromium browser in the container?

[FirbyKirby]

FYI - I found an open issue on the browser balenablock that seems like it may be related. I've cross-referenced these two issues. I'm certainly no expert, but based on further confirmation that the time displayed when rendered in my development computer browser (firefox) is indeed local time, while the time rendered in the browser container remains UTC, I feel like the issue is most likely in the browser container, and not in the NetStatus container.

[Ryandev]

Hi,

Sorry for the late reply. I've just been looking into this myself & as far as I can tell, NetStatus is doing the right thing here.

The relevant line is here file:offline.map.ts:

    const timeFormat = **new Intl.DateTimeFormat('en', { hour: 'numeric', minute: 'numeric' });**
    return {
        title: "Connection Lost!",
        subtitle: "Last online at " + timeFormat.format(state.OnlineStatus.dateWasLastOnline),
        iconName: "plug",
    };

So it's asking the system to format the date, there's nothing set for UTC.

When you load up the public url:https://netstatus.ryanpowell.dev/loading does it respect your local timezone or display in UTC?

I can't test your exact scenario, however setting my geolocation to USA-WestCoast in chrome dev-tools I get a time in the browser which doesn't match my local-machine. Which is what you would expect.

By the looks of things so far, it does point to a deployment issue. Whether it's balena or chromium setup within. I don't know yet.

[Ryandev]

It looks like upon boot, Chrome/Chromium will respect the environment variable 'TZ' & override the system timezone from the browser.

On my machine running:

export TZ="America/Winnipeg"
open -n -a /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --args --user-data-dir="/tmp/chrome_dev_test" --disable-web-security

As before the date/time listed doesn't match my local machine. In theory setting the TZ env in the balena cloud should resolve this. As it looks like you've already tried this.

My only suggestion would be to check your changes are getting pulled through onto your device. SSH'ing in & checking the env TZ is present?

[FirbyKirby]

Thanks for the dedicated work researching and resolving this issue. Just to close the loop, TZ (and other) environment variables were getting pulled into the container. But as noted in the linked issue on the balenablocks issue tracker, the problem was in how Chromium was handling the TZ variable. I'm no expert, but as far as I can tell from the pull request that resolved the issue, it seems the problem was a permissions issue within the container.

For anyone reading this in the future, ensure you have the balenablocks browser version 2.0.3 (visible in the logs when booting up the container) to properly pull TZ forward from the device's environment variables into Chromium.

Also, mostly unrelated to this issue, I'm trying my hand at a modification to offline.map.ts. My use case involves internet outages that may last for days (rural broadband in the US is particularly bad.) I'm attempting to add a date to the lost connection display if the connection loss is greater then a day. So, with any luck, I'll have a pull request for you soon.