Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
This answer and comments mention --rfc-3339 and a "hidden" --iso-8601 option that I have used for a long time and now seems to be undocumented.
When did that option documentation get removed from the --help text?
Will the option go away anytime soon?
The option was introduced in the coreutils date (which is probably what you have) in 1999 (Apr. 8).
The documentation was removed in 2005 without much explanation in the commit.
In 2011, the help for --iso-8601 was reintroduced with the following explanation:
We deprecated and undocumented the --iso-8601 (-I) option mostly
because date could not parse that particular format. Now that
it can, it's time to restore the documentation.
* src/date.c (usage): Document it.
* doc/coreutils.texi (Options for date): Reinstate documentation.
Reported by Hubert Depesz Lubaczewski in http://bugs.gnu.org/7444.
It looks like the help was taken out in version 5.90 and put back in, in version 8.15 (it is not in my 8.13) and the comment above suggests that it is now back to stay and not likely to be disappearing any time soon.
In version 8.31 (as provided by Solus July 2020) the man page descriptions for two two options are:
-I[FMT], --iso-8601[=FMT]
output date/time in ISO 8601 format. FMT='date' for date only (the default), 'hours', 'minutes', 'sec‐
onds', or 'ns' for date and time to the indicated precision. Example: 2006-08-14T02:34:56-06:00
--rfc-3339=FMT
output date/time in RFC 3339 format. FMT='date', 'seconds', or 'ns' for date and time to the indicated
precision. Example: 2006-08-14 02:34:56-06:00
For a platform independent, (almost) fully compliant, ISO 8601 date use this:
date +"%Y-%m-%dT%H:%M:%S%z"
This will result in a time such as: 2021-01-16T23:09:44-0500
This should work on BSD and Linux.
Technically, for full compliance it should be:
date +"%Y-%m-%dT%H:%M:%S%:z"
(Note the offset has a colon it it.) This will result in a time such as: 2021-01-16T23:09:44-05:00
But this doesn't work on Mac OSX (as of this writing).
For UTC time (zero offset) you can use (note the -u):
date -u +"%Y-%m-%dT%H:%M:%SZ"
This will result in a time such as: 2021-01-17T04:16:14Z
% date +"%Y-%m-%dT%H:%M:%S%:z" yields 2022-03-22T11:05:42:z on Darwin 21.3.0 Darwin Kernel Version 21.3.0.
date does not understand the %:z format control. Check your output thoroughly, it wrote literal :z instead of your time zone with the : separator like for example date +%:z -> +02:00 --- Also shell normally has nothing to do with this because date is normally an external executable, not the shell's built-in.
May 6 at 15:12
The --help got an update recently actually, so the option definitely isn't going away:
-I[FMT], --iso-8601[=FMT] output date/time in ISO 8601 format.
FMT='date' for date only (the default),
'hours', 'minutes', 'seconds', or 'ns'
for date and time to the indicated precision.
Example: 2006-08-14T02:34:56-06:00
-R, --rfc-2822 output date and time in RFC 2822 format.
Example: Mon, 14 Aug 2006 02:34:56 -0600
--rfc-3339=FMT output date/time in RFC 3339 format.
FMT='date', 'seconds', or 'ns'
for date and time to the indicated precision.
Example: 2006-08-14 02:34:56-06:00
Note since coreutils-8.27 --rfc-2822 is deprecated in favor of the more general --rfc-email
-R, --rfc-email output date and time in RFC 5322 format.
Example: Mon, 14 Aug 2006 02:34:56 -0600
-I style without the timezone. Would be more useful for logging, etc, where the timezone doesn't matter
Jan 17, 2019 at 5:56
I'm running Linux Mint and the option is available:
$ lsb_release -a
No LSB modules are available.
Distributor ID: LinuxMint
Description: Linux Mint 17.3 Rosa
Release: 17.3
Codename: rosa
The execution of the command:
$ date --iso-8601=seconds
2016-12-14T09:53:25-0400
Z to the end so this is not fully complete ISO timestamp
Jan 7, 2020 at 10:34
date -In (same as date -Ins) or date -Is same as (date -Iseconds) etc.
+00:00 is the same as Z. +00:00Z is not correct.
Jul 20, 2021 at 17:08