[Feature] Simplified timezone

[jonsmirl]

Feature description

The time source cluster is a complex, per fabric solution which I am not finding to be useful.

Embedded chips don't have complex timezone databases. What they all have support for is Posix timezone strings and NTP. Example timezone strings....

"America/Guyana" to "<-04>4",
"America/Halifax" to "AST4ADT,M3.2.0,M11.1.0",
"America/Havana" to "CST5CDT,M3.2.0/0,M11.1.0/1",
"America/Hermosillo" to "MST7",
"America/Indiana/Indianapolis" to "EST5EDT,M3.2.0,M11.1.0",
"America/Indiana/Knox" to "CST6CDT,M3.2.0,M11.1.0",
"America/Indiana/Marengo" to "EST5EDT,M3.2.0,M11.1.0",
"America/Indiana/Petersburg" to "EST5EDT,M3.2.0,M11.1.0",

Phones apps can access the time zone name such as "America/Hermosillo" from the OS API. A small table (around 20KB in the phone app) can convert from the zone name to the Posix string. (if you want to get fancy in the phone app you can build those strings from a timezone database, I just used a look up table).

During setup the phone app would set the TZ string into the node and then the node would just use standard NTP as a timesource. This works cross fabric and it is very easy to implement on existing embedded platforms. I see no benefit to the complex, per fabric (what if the fabrics don't agree on the time?) clusters in the Matter specification.

Platform

all

Platform Version(s)

No response

Anything else?

No response

[bzbarsky-apple]

This seems like a spec request, not an SDK request. @cecille

[cecille]

Time zone is not set per fabric. The only fabric specific pieces of the time sync cluster is the trusted time source (there is only one, but it is fabric-specific).

This is a spec request.

[cecille]

I'm not sure I fully understand the request though - would the requested change be to have the devices mark that they support only the shortened names for time zones and have the administrator use the shortened names in the time zone table?

Right now, devices are allowed to use their own time zone database and NTP if it's supported.

[jonsmirl]

Timezone databases are over 2MB in size, way too big for embedded microcontrollers. So how do you communicate GMT offset and daylight savings time to a tiny microcontroller? Most microcontrollers large enough to be used with Matter support NTP and Posix TZ strings.
https://github.com/nayarsystems/posix_tz_db/blob/master/zones.csv you can generate these TZ string from a full 2MB time zone database. https://github.com/nayarsystems/posix_tz_db

The first colunm in zones.csv is the time zone name. You can get the timezone name from IOS/Android system APIs.

So what I did is make a custom Matter attribute for this TZ string and populated it during setup via the phone. Zone.csv is embedded in the phone app. The microcontroller OS then combines this TZ string with GMT NTP to produce local time. My devices don't have persistent clocks so on each boot they synchronize via pool.ntp.com. That works well because many routers will implement a local NTP proxy. If the politicians decide to change timezones the phone setup app can update the TZ string.

Consider that the existing Matter Time Source Cluster is fabric specific. What happens if the fabrics don't agree on what time it is? (like one fabric has the wrong timezone set). This mechanism using TZ strings and NTP works cross fabric. Since it is not fabric specific, it can't get into a state of disagreement.

It is also extremely easy to implement. I had the full implementation from phone app down to device running NTP working in a day including building the custom attribute for the TZ string. I found the system in the Matter spec to be far more complex than necessary, hard to implement (needs a master source device), and it provided no real advantages.

[jonsmirl]

If you disagree with NTP on security grounds and want to use Matter encrypted sessions, I would still endorse using TZ string global attributes and then just provide a GMT time source via the Matter protocol. Doing it that way ensures that the fabrics can't disagree on what the timezone is. The downside -- devices have to locate a Matter time source and each fabric has to provide one because they can't tell if the other fabrics also provide one. Note that if DST offset processing is done at a root node, then the leaf devices will have to handle events for begin/end of the period to know when to adjust their local clocks.

[cecille]

NTP is allowed and supported by the cluster. This is fine. The time zone name is already populated in an attribute - it is part of the TimeZoneStruct in the TimeZone attribute - devices are specifically allowed to use this time zone name for time zone operations:

The time zone name SHOULD provide a human-readable time zone name and it SHOULD use the country/city format specified by the [IANA Time Zone Database](https://spang.users.x20web.corp.google.com/www/connectedhomeip-spec/index.html#ref_IanaTimeZones). The Name field MAY be used for display. If the node supports a TimeZoneDatabase it MAY use the Name field to set its own DST offsets if it has database information for the supplied time zone Name and the given Offset matches.

The time zone cluster is NOT fabric specific. There is a singular cluster for the node.

[cecille]

The time zone cluster is implemented as it is because it is intended to support both devices that have NTP support AND devices that do not. The features a device opts to implement define how the time is obtained. It sounds like you've implemented a device that supports the TZ and NTPC features, basically.

[jonsmirl]

The remote cluster the device is getting the time information from is fabric specific. If an Apple Home Pod is providing time info, my device can't see it unless it is on the Apple fabric.

[cecille]

Yeah, but if you have NTP, you don't need to do that.

[jonsmirl]

Consider this from the device manufacturer side. My device has a clock display. That clock display needs a time source. Where do I get one?

I can't count on Matter to provide me with a time source since I don't know which vendor fabrics the device will be commissioned onto and if those fabrics will have a time source. The only reliable choice I have is NTP which provides GMT.

Then you hit the next problem, how do I display local time? The easiest solution to that is to use your phone to determine the timezone. It has a GPS and knows where it is. Once you know the timezone you can make the TZ string and set it into the device. This is one thing I do need: A standard Matter attribute to hold this TZ string.

Next I would propose that if you do use a Matter based time source instead of NTP, it would be better if those per fabric time sources only provided GMT. That way they can't get into disagreement because their timezones are set wrong. The device would get GMT from the Matter time source and then locally apply the TZ string for GMT offset and DST.

[cecille]

Yes, that's why NTP was added as an option - in case a device doesn't want to rely on having an available node with a time source. For some devices, NTP is not an option, which is why the time sync client was also added as an option.

Time zone set by the commissioner, and this setting is persistent. The time zone name is part of this setting. This is already part of the standard attribute. Please see TimeZoneStruct. That holds both the name and the offset, so it can ALSO be used by devices that do not support a time zone database.

The SetUTCTime command is used to set the time in UTC. Local time is calculated from that. UTC time is also exposed as an attribute.

[jonsmirl]

In DSTOffsetStruct the start and stop dates are given as epoch which will have to be recomputed every year. The encoding used in zones.csv works for every year until the politicians change it.

[jonsmirl]

In TimeZoneStruct that name is optional. Can't count on it being there. If you'd add ID3 PosixTZ-string and make it mandatory, that would be enough for me. The key to the Posix TZ is that it also encodes DST in a perpetual manner. I don't see how to compute a perpetual DST formula from the data in the Time Sync cluster since DSTOffsetStruct is using epoch.

[cecille]

yes, and that was intentional for small devices that do not have time zone database support or calendars because the calculations required to understand all the DST settings may not be available on a small device. It's also why the DST offsets are given as a list that can cover multiple years. Devices that DO have a time zone database are welcome to populate this attribute on their own on an ongoing basis as they see fit.

Over time, if the node supports a TimeZoneDatabase and it has information available for the given time zone name, it MAY update its own list to add additional entries.

[cecille]

Realistically, anything that comes from an administrator is optional. Commissioners SHOULD do these things, but as an end device, you have little recourse if they don't. If you write your own administrator, as it appears you have with your phone app, you can include it. If you're depending on an ecosystem to populate it, as with all things, you take your chances. Most will, because there's no reason not to.

[cecille]

I think I'm not totally understanding what the gaps are here, but I'd encourage you to open a spec issue or a TCR if you have a particular suggestion for which attributes or controls are missing.

[jonsmirl]

From the perspective of someone implementing a device using a tiny microcontroller, I am not finding the Time Sync cluster to be useful. It is too complex and too full of optional pieces and it relies on a per fabric time source. The code needed to implement Matter Time Sync on my device is much larger than using a far simpler alternative like NTP+TZ-string.

[cecille]

If you have NTP, you don't need to support the time source at all. Just do not include the TSC feature. I think what you're looking for is a cluster with the TZ and NTPC feature.

The alternative is to just use NTP and not implement the cluster at all. There's nothing saying the cluster is required.

[jonsmirl]

In my current implementation I have time wired to pool.ntp.org and then a custom cluster to set the TZ string. I get the TZ string during commissioning since it is easy for a phone app to provide it. After looking at TSC I did not want to implement it because of the complexity.

A question to ask, does the TSC really add anything useful over using a much simpler mechanism? From my perspective the answer to this is no. Why reinvent the wheel? NTP works just fine over Thread and Wifi.

[cecille]

That's why NTP was added as an option. But there are definitely devices that do not wish to implement NTP, but wanted an option for a fallback. Mostly for sleepy devices. It is currently in use in some devices that have been certified.

[jonsmirl]

The lowest power way for a sleepy device to do time is for the commissioner to directly set the time and TZ-string into an attribute of the sleepy device. Then the sleepy device would use its typical 32Khz crystal to track time and the TZ string to compute DST. No need for a network. Every once in a while you could reset the clock over the network to compensate for drift.

My device doesn't have a battery. When power fails the time is lost and then NTP recovers it.

[cecille]

That is, in fact, what happens in most cases. For cases where there is a resident device with a warm case connection and admin access, the admin will set the time if it is required and check that the required attributes are set when the case session is established. The client read option is a fallback that was requested by device manufacturers.