Earlier quoted context omitted.
There are several standards that specify how offsets should appear, but only Go uses Z (meaning Zero offset, aka UTC equivalent) followed by what appears to be a _positive_ number to represent a _negative_ offset... 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.
You are misunderstanding what you are seeing. The Z does not represent a literal Z in parsing/formatting. https://play.golang.org/p/Qp-bBtzKpG-
A simple file encryption tool and format
21–29 of 29 posts
Re: A simple file encryption tool and format
#22Please please please use standard command line flag format (getopt_long) instead of the Go’s flag format. It’s super irritating that Go programs do it their own, less convenient way. For example: https://github.com/DavidGamba/go-getoptions
Re: A simple file encryption tool and format
#23I had another look at `age` a week or two ago to see what progress had been made, and I couldn’t find any code. I would be delighted to be able to ditch gpg...
Re: A simple file encryption tool and format
#24Could update link to age-tool.com.
I tried that link but got re-directed to the original Google Docs page. It sounds like a really interesting tool, but I haven't been able to find the actual code anywhere.
Re: A simple file encryption tool and format
#25Re: A simple file encryption tool and format
#26Ugh, Go fails to parse RFC-3339 [0] correctly so our best hope for "Actually Good Encryption" will end up with badly formatted timestamps. Timezone 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…
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.
Re: A simple file encryption tool and format
#27Ugh, Go fails to parse RFC-3339 [0] correctly so our best hope for "Actually Good Encryption" will end up with badly formatted timestamps. Timezone 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…
> will end up with badly formatted timestamps. 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.
Re: A simple file encryption tool and format
#28Please please please use standard command line flag format (getopt_long) instead of the Go’s flag format. It’s super irritating that Go programs do it their own, less convenient way. For example: https://github.com/DavidGamba/go-getoptions
I’m not sure I understand, what’s the difference? I’ve never had any problems using go programs’ command line flags myself.
The application in question is using -generate rather than --generate.
Re: A simple file encryption tool and format
#29Please please please use standard command line flag format (getopt_long) instead of the Go’s flag format. It’s super irritating that Go programs do it their own, less convenient way. For example: https://github.com/DavidGamba/go-getoptions
I’m not sure I understand, what’s the difference? I’ve never had any problems using go programs’ command line flags myself.
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 -F