Node-RED (in FlowFuse) should be able to use system time of the host on which it is running

[robmarcer]

Description

For a NR instance, I can manually select a timezone (https://d.pr/i/KOQGVy), I want to be able to select 'System Time' from that list so deployments of NR to multiple timezones can use the local time in each instance/device.

Which customers would this be available to

None

Have you provided an initial effort estimate for this issue?

I can not provide an initial effort estimate

[robmarcer]

This is for https://app-eu1.hubspot.com/contacts/26586079/record/0-2/8845845707

I can hack around this but it's an ugly hack. I would be happy to discuss alternative solutions if there is one. the goal is to be able to reset counts:

1. midnight (local time) on remote devices.
2. at the end of the week which is a different point in time dependant on the culture and timezone a factory is within. We can pass in which day that factory considers to be the end of the week so this is basically still the same as scenario 1 above.

[hardillb]

Just checking, this is for devices only?

We basically want an option to not set the TZ env var for a device so it picks up the local one.

[robmarcer]

I would want to set the the zone as local in prior stages of the dev-ops pipeline so ideally it would be for both. For now it would unblock us if we had it for devices only as we are only using devices in the specific pipeline's dev stage.

[hardillb]

But local for a cloud instance is not always going to make sense.

E.g. FF Cloud will ALWAYS be UTC by default

[joepavitt]

Just to add to this, local=time for remote instances makes sense, but not for hosted, as Ben has pointed out, this will always be UTC.

So, to clarify, the request here is to have a "Local" option in a (new) "Timezone" field on a Device, as there is no equivalent option here at the moment I believe.

[hardillb]

But also all the Node-RED log output in the FlowFuse app is always displayed in the browsers local timezone, this is just what time things like inject nodes will fire at

[hardillb]

I think this is going to need multiple parts

First, where the timezone is set in the frontend UI will need an extra option adding to the list of available options

Second, both the nr-launcher and the device agent will need to be updated to copy the existing (if it exists) TZ env var from the host to the scope of the running Node-RED instance.

We will also need to consider how the existing nr-launcher/device agent will behave if they get this now non-sense value.

[hardillb]

We do not explicitly set a timezone for a device. Need to look how it's set from a pipeline or when bound to an instance

[hardillb]

The device agent already should be using the local device setting if it's set

        // Use local timezone if set, else use one from snapshot settings
        // this will be ignored on Windows as it does not use the TZ env var
        env.TZ = process.env.TZ ? process.env.TZ : this.settings?.settings?.timeZone

This may be unix only, need to check how windows behaves

[hardillb]

OK, there is no TZ env var on Windows by default.

@robmarcer I need a clearer understanding of this request. What is the full usecase here.

Are we talking about deploying to a selection of devices in different timezones? If so this should work if the timezone is set locally unless the devices are on Windows (or an environment where TZ is not set by default e.g. Docker).

If this is Docker, then we can inject the local timezone into the container and things should work as expected.

[robmarcer]

Yes, we are deploying snapshots to a combination of instances of NR running both directly on a FF server and on devices across various timezones. The goal is to be able to find out the timezone NR is running in.

[robmarcer]

Just to add to this, local=time for remote instances makes sense, but not for hosted, as Ben has pointed out, this will always be UTC.

So, to clarify, the request here is to have a "Local" option in a (new) "Timezone" field on a Device, as there is no equivalent option here at the moment I believe.

I'm unsure why a FF instance would not set the time based on its own settings. For example, if FF is running in Germany, instances of NR running on that server should be able to discover the local time rather than use UTC.

[hardillb]

I'm unsure why a FF instance would not set the time based on its own settings. For example, if FF is running in Germany, instances of NR running on that server should be able to discover the local time rather than use UTC.

This is not the case. For the customer environment this is coming from, FF is running in Docker. Docker containers all run in UTC, unless explicitly pass the TZ environment variable into the container (and possibly mount the tzdatabase as well)

Same goes for the Device Agents running in Docker, they have no way of knowing what the host machines timezone is unless it is explicitly set.

My best suggestion so far is to have a flag for the device-agent that will ignore any timezone passed in with the snapshot and use the local TZ if set.

[hardillb]

The Device agent will already default use the local timezone if set

https://github.com/FlowFuse/device-agent/blob/332475212d3741d7b577521c3ba52688a48e2a9d/lib/launcher.js#L476-L478

@robmarcer So if the customer sets the TZ environment variable in the container definition this should "just work"