Fix RFC3339 typo in docs

[IJMacD]

- What I did
Edited the docs

- How I did it
N/A

- How to verify it
N/A

- Description for the changelog

Fix RFC3339 typo in docs

- A picture of a cute animal (not mandatory but encouraged)

[vvoland]

Thanks!
There are also other occurrences of this:

docs/reference/commandline/network_prune.md
47:`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local

docs/reference/commandline/system_events.md
113:`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local

docs/reference/commandline/logs.md
50:`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local

docs/reference/commandline/service_logs.md
66:`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local

docs/reference/commandline/events.md
151:`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local

docs/reference/commandline/image_prune.md
72:`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local

docs/reference/commandline/container_prune.md
49:`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local

man/src/system/events.md
27:`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local

Would you be interested in correcting them as well?

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.73%. Comparing base (1583484) to head (64c20f3).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3975      +/-   ##
==========================================
- Coverage   61.76%   61.73%   -0.03%     
==========================================
  Files         297      294       -3     
  Lines       20768    20763       -5     
==========================================
- Hits        12828    12819       -9     
- Misses       7024     7026       +2     
- Partials      916      918       +2     

[thaJeztah]

I was wondering of some of this was intentional (but admitted; I always get confused on Go's time format strings); also because Z is described further down, and looking at https://github.com/moby/moby/blob/17b2c89116a3fa9ebfe24b38000365096dc8bdc2/api/types/time/timestamp.go#L11-L18

// These are additional predefined layouts for use in Time.Format and Time.Parse
// with --since and --until parameters for `docker logs` and `docker events`
const (
	rFC3339Local     = "2006-01-02T15:04:05"           // RFC3339 with local timezone
	rFC3339NanoLocal = "2006-01-02T15:04:05.999999999" // RFC3339Nano with local timezone
	dateWithZone     = "2006-01-02Z07:00"              // RFC3339 with time at 00:00:00
	dateLocal        = "2006-01-02"                    // RFC3339 with local timezone and time at 00:00:00
)

[vvoland]

Yeah I looked into it, it's a bit misleading because 2006-01-02Z07:00 is expected to parse dates with timezone, but without time. So:
time.Parse("2006-01-02Z07:00", "2023-01-18Z16:02") = error
time.Parse("2006-01-02Z07:00", "2023-01-18+03:00") = ok, 2023-01-18, time 00:00, offset +3h

[IJMacD]

@vvoland I have pushed changes to the other files you mentioned.

I agree that Go's time format specifiers and accompanying documentation in incredibly misleading and leads to slip ups like this propagating across the ecosystem.

2006-01-02Z07:00 is valid as a format specifier in Go; it is never a valid value.

The change in this pull request is the minimal diff to get valid ISO 8601 values in the Docker docs i.e. 2006-01-02T07:00 changing Z to T to make a combined date-time representation (at 7 am local time)

I can't be sure but the Go docs seem to suggest the format specifier 2006-01-02Z07:00 would accept the following values implying 00:00:00 in UTC or local time. However, neither of the following is valid under ISO 8601 [1].

{ 2006-01-02Z, 2006-01-02+07:00 }

[Ref 1: ISO 8601-1:2019 § 5.4.2.1]

[vvoland]

LGTM, thanks!

[vvoland]

Sorry for the delay; rebased so we can get this in. Thanks!