For example: https://github.com/DavidGamba/go-getoptions
The application in question is using -generate rather than --generate.
The standard on most UNIX-like OSes is that long options, e.g. --long, have two dashes, and short options, e.g. -l, have one.
It allows you to combine multiple options into one. For example, the following two commands are equivalent:
$ ls -laF
$ ls -l -a -FTimezone offsets should be represented by either a "+" (positive offset) for hours added to UTC in zones East of the prime meridian, or a "-" (negative offset) for zones to the West.
The Z suffix (meaning Zero hours offset from UTC, from the phonetic alphabet for "Zulu"), if it is used, should be the last character in a zero-offset (UTC) timestamp. However a UTC timestamp may instead be represented by a numeric offset of +00:00 hours.
The issue is that Go has, I believe misinterpreted the RFC and so presents the example timestamp:
2006-01-02T15:04:05Z07:00
which has a Z (meaning UTC), and then an ambiguous offset from it.In that example the "Z" should be a "-" as all the examples are set in the Mountain Standard Timezone. RFC-3339 is quite clear that numeric offsets should be prefixed by either a "+" or a "-", or that a "Z" may be used instead when there is no offset.
An issue [1] was raised on their Github, the first post of which explains the problem clearly, but somehow the replies got distracted with whether the colon in numerical offsets is optional or not, and was subsequently closed.
[0]: https://tools.ietf.org/html/rfc3339#section-5.6 [1]: https://github.com/golang/go/issues/31113
From the docs:
Replacing the sign in the format with a Z triggers the ISO 8601 behavior of printing Z instead of an offset for the UTC zone.
By this logic we can expect to see a Moscow time stamp represented as HH:MM:SS+03:00 in every other program, and HH:MM:SSZ-03:00 only in Go.
It's just wrong, for no good reason.
I'm not sure why you think that. If rfc3339 format is required, then either a custom formatter can be created or a 3rd party lib can be used. Go may be silly in its stdlib, but it doesn't stop you from doing the right thing.
That said, I think it's excellent that they guys behind this are taking the time to think it out and design it well before they start slinging code. I believe a much better end result will be achieved because of it.
https://gnupg.org/documentation/manuals/gnupg/symcryptrun.ht...
Now somebody just needs to write it in Rust or Haskell...
Yawn.