Tim Thornton wrote:
Also, it uses GMT (i.e. UT1, not UTC) - I'm not sure if the tz database can cope with this,
The tz database is effectively silent on which flavour of UT is the basis for timezone offsets. Its offsets are not meaningful at a subsecond level. The maritime timezone system also long predates the need to distinguish flavours of UT, and I'd be surprised if it really is specified to use UT1 rather than UTC. So, in any case, the tz database can represent the maritime timezones just fine.
So they could be included in the TZ database
They are. See the zones Etc/GMT-12 to Etc/GMT+12, in the "etcetera" source file. (There are also a couple more fixed-offset zones that are outside the maritime system.) Beware that the sign in the zone's name is the opposite of the offset's sign, due to an historical confusion with the negated-sign aspect of POSIX TZ format. The initialisms of these zones match the names, and do not use the maritime letters. A single-letter initialism would be a problem, because the POSIX TZ format requires initialisms to be at least three characters, so a time-using program might reasonably expect the initialism to be at least three characters. The Theory file has a note about sticking to this. However, aside from the historical fact of them already being in the database, fixed-offset zones are generally out of scope for the tz database. In general if you want a fixed offset, and in particular if you want a fixed offset with an initialism based on the nautical letters, I suggest that you use an actual POSIX TZ value. For example: TZ=seaA-1 TZ=seaM-12 TZ=seaN1 TZ=seaY12 TZ=seaZ0 -zefram