You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While half hour timezones do exist, so far as I'm aware neither +00:30 or -00:30 is used (or anything else between +01:00 and -01:00 exclusive) so I'm not sure it is actually erroneous to define in that way. There's possibly a good reason for why the second is written that way too, @adamretter do you have any idea?
That is true. However, I still think the inconsistency is worth addressing. Which timezones currently exist can change, and it is also conceivable to have data at a time offset that does not correspond to a commonly accepted timezone. This is something the currently specified regex reflects (e.g. +01:42), just not for offsets beginning with 00. Moreover, the offsets +00:00 & -00:00, are also not valid with the current regex. While they are equivalent to Z, I feel it would be arbitrary to forbid these values. In particular, since the referenced data type specification (3.7.2.3) permits these values as well.
Both the regex for
XsdTimezoneComponent
as well as for the optional variant are erroneous:This does not allow for timezones with two leading zeros, e.g.
+00:30
.On a similar note, the minute-part of the regex could be simplified from
0[0-9]\|[1-5][0-9]
to[0-5][0-9]
.The text was updated successfully, but these errors were encountered: