The handling of Local timezones includes code to parse both timezone information files and Posix timezone strings. This code is currently driven from either a TZ environment variable or a /etc/localtime symlink. But it seems there is no public API available to create these timezone manually from either a file or a string.
It would be useful to have a public API where you could do something like TimeZone::from_file() and TimeZone::from_posix_string(). This is probably mostly useful in (embedded) no-std scenarios where there is no concept of a 'configured' timezone on the OS level and timezone information comes from application specific configuration. There might be other uses too. A minor side benefit would be that it would allow for easy testing against for instance all timezone files as generated from the Iana database.
For handling files tzfile does exist, but it has some limitations because it doesn't handle Posix strings and therefore cannot do far future transitions. But more importantly, the required code is already present in Chrono anyway so it seems somewhat useless to duplicate it.
The handling of Local timezones includes code to parse both timezone information files and Posix timezone strings. This code is currently driven from either a TZ environment variable or a /etc/localtime symlink. But it seems there is no public API available to create these timezone manually from either a file or a string.
It would be useful to have a public API where you could do something like
TimeZone::from_file()
andTimeZone::from_posix_string()
. This is probably mostly useful in (embedded) no-std scenarios where there is no concept of a 'configured' timezone on the OS level and timezone information comes from application specific configuration. There might be other uses too. A minor side benefit would be that it would allow for easy testing against for instance all timezone files as generated from the Iana database.For handling files tzfile does exist, but it has some limitations because it doesn't handle Posix strings and therefore cannot do far future transitions. But more importantly, the required code is already present in Chrono anyway so it seems somewhat useless to duplicate it.