Adding a human readable timezone string in addition to the existing numerical offset is just creating opportunities for inconsistencies between the numerical and string values. Now there is extra special syntax for whether the application MUST act on detected inconsistencies, or whether it's safe to ignore it. Better to avoid defining an inconsistent format in the first place.
Projecting the timestamp into a specific calendar seems more like a localization problem than something that should be specified in the timestamp itself.
Adding support to bundle custom metadata key:value pairs into timestamp strings also seems misguided? Let timestamps be timestamps, if you need a more use a proper type instead of passing around timestamp strings.
edit: I can see the reasoning for the proposal, but I think it just doesn't get there. On the one hand it adds some confusing complexity to what is otherwise a very simple format to deal with. On the other, it's clearly not going to be sufficient for developers of complex non-gregorian/multi-calendar applications.
Adding a human readable timezone string in addition to the existing numerical offset is just creating opportunities for inconsistencies between the numerical and string values. Now there is extra special syntax for whether the application MUST act on detected inconsistencies, or whether it's safe to ignore it. Better to avoid defining an inconsistent format in the first place.
Projecting the timestamp into a specific calendar seems more like a localization problem than something that should be specified in the timestamp itself.
Adding support to bundle custom metadata key:value pairs into timestamp strings also seems misguided? Let timestamps be timestamps, if you need a more use a proper type instead of passing around timestamp strings.
edit: I can see the reasoning for the proposal, but I think it just doesn't get there. On the one hand it adds some confusing complexity to what is otherwise a very simple format to deal with. On the other, it's clearly not going to be sufficient for developers of complex non-gregorian/multi-calendar applications.