On 07/12/2024 02:19, Arthur Olson via tz wrote:
May be prudent to keep Etc/Factory and Etc/Unknown separate to guard against the possibility that a vendor does something funky with Factory (such as automatically modifying the distribution so that Factory is their local time). There's a small price to pay given the small sizes of the existing Factory and proposed Unknown binaries.
The two are different 'concepts' and should not be considered as being mirrors of one another. That one does not know what timezone data should be used IS 'Unknown' is a fact and in general is outside the scope of the database, but having an entry to identify that fact would be prudent? Naturally it would have an offset value of zero so any time value would be handled as UTC. Geographic databases that supply a timezone identifier may well return a 'NULL' value if there is no matched entry and then there are other steps that are perhaps needed, again outside the scope of the tz database, that could provide a better offset than using UTC directly. Such as a simple 'solar' offset which has nothing to do with 'Factory' and is application dependent. A cross project agreement on a standard method of handling an unknown value of tz identifier is also outside the scope, but then that is why this thread has come into existence? -- Lester Caine ------------