cmd/observe: add a new flag to allow specifying different time formats for timestamps

[rolinh]

This PR adds a new option to the observe command (--time-format) to allow specifying a different time format for timestamps. The default is unchanged and remains time.StampMilli. The following formats are supported:

      --time-format string   Specify the time format for printing. This option does not apply to the json and jsonpb output type. One of:
                               StampMilli:   Jan _2 15:04:05.000
                               RFC3339:      2006-01-02T15:04:05Z07:00
                               RFC3339Milli: 2006-01-02T15:04:05.999Z07:00
                               RFC3339Micro: 2006-01-02T15:04:05.999999Z07:00
                               RFC3339Nano:  2006-01-02T15:04:05.999999999Z07:00
                               RFC1123Z:     Mon, 02 Jan 2006 15:04:05 -0700
                               (default "StampMilli")

In addition, new formats are supported for the --since and --until flags, namely RFC3339 and RFC3339[milli|micro|nano] and RFC1123Z.

[kaworu]

Test failures are legit https://github.com/cilium/hubble/pull/509/checks?check_run_id=2086620687 e.g.

            	Diff:
            	--- Expected
            	+++ Actual
            	@@ -1,2 +1,2 @@
            	-TIMESTAMP: Jan  1 00:20:34.567
            	+TIMESTAMP: 1970-01-01_00:20:34.567
            	      SOURCE: 1.1.1.1:31793
Test:       	TestPrinter_WriteProtoFlow/dict

[kaworu]

Personally, I'm not too surprised that the default human readable format cannot be parsed back to a time.Time. The double-click selection depends on the terminal and it's double-click selection delimiters (AFAIK it's sometimes configurable). What I'm trying to say is that the proposed format doesn't guarantee double-click will select the full "time field" as one can have colon (:) as delimiter.

Overall I feel we loose human readability for a use-case that would be better served using another output format, but I don't feel too strongly either way.

[rolinh]

Overall I feel we loose human readability for a use-case that would be better served using another output format, but I don't feel too strongly either way.

What about adding a new flag to specify the time format? We could keep the existing one but it would allow using different ones.

[michi-covalent]

looks good to me overall. a few comments/suggestions.

• makes sense to add a new flag to specify the timestamp format.
• i prefer to stick to standard format, for example 1985-04-12T23:20:50Z if we are using rfc3339.

[rolinh]

@michi-covalent I've completely reword the PR to add a --time-format option and the default layout remains unchanged. PTAL.