0

I can't seem to find any simple answers as to how to get the date 2022-03-17T08:06:20.411493824Z with a simple bash command. The current date and time that is.

I tried the following, but I'm not getting the excess digits:

DATE=$(date '+%FT%TZ')

echo $DATE
1
  • On what operating system? The specifics will depend on what date implementation you are using.
    – terdon
    Commented Mar 17, 2022 at 14:32

2 Answers 2

5

If you’re looking for the UTC time using ISO 8601 format, with nanoseconds, using GNU date:

date -Ins -u

If you’re after your exact format, still in UTC using GNU date:

date -u +%Y-%m-%dT%H:%M:%S.%NZ

or

date -u +%FT%T.%NZ
2
  • 1
    Ah so it was the %N that was tricking me! Commented Mar 17, 2022 at 9:24
  • GNU date is not the only one implementation supporting %N. FreeBSD's date(1) has this functionality since version 14.1. Commented May 27 at 8:33
3

If you don't have access to GNU date (does it even make sense to get nanosecond precision when invoking date alone takes a few thousands if not millions of those), but if switching to other shells is an option, you can do:

In zsh:

TZ=UTC0 print -rP '%D{%FT%T.%9.Z}'

(here using prompt expansion via print -P)

Or:

zmodload zsh/datetime
TZ=UTC0 strftime %FT%T.%9.Z $epochtime

Or to store in a variable:

TZ=UTC0 print -rPv var '%D{%FT%T.%9.Z}'

Or:

zmodload zsh/datetime
TZ=UTC0 strftime -s var %FT%T.%9.Z $epochtime

Or:

() { local -x TZ=UTC0; var=${(%):-%D{%FT%T.%9.Z}}; }

With ksh93:

TZ=UTC0 printf '%(%FT%T.%NZ)T\n'

Or to store in a variable:

var=${ printf '%(%FT%T.%NZ)T'; }

bash did copy a subset of ksh93's printf '%(format)T' datespec a few years back, but does not support %N for nanoseconds.

Since version 5.0, it added support for the $EPOCHSECONDS and $EPOCHREALTIME variables (not $epochtime array) from zsh. Only with microsecond precision, but may be enough for your use case:

t=$EPOCHREALTIME; TZ=UTC0 printf "%(%FT%T)T.${t#*.}Z\n" "${t%.*}"

All of those use only builtins and don't fork any process, so you should be able to run quite a few per millisecond.

$ repeat 10 TZ=UTC0 print -rP '%D{%FT%T.%9.Z}'
2022-03-17T12:04:56.563450377Z
2022-03-17T12:04:56.563488246Z
2022-03-17T12:04:56.563512375Z
2022-03-17T12:04:56.563530355Z
2022-03-17T12:04:56.563545833Z
2022-03-17T12:04:56.563559764Z
2022-03-17T12:04:56.563575171Z
2022-03-17T12:04:56.563594030Z
2022-03-17T12:04:56.563611980Z
2022-03-17T12:04:56.563626251Z
$ repeat 10 date -u +%FT%T.%NZ
2022-03-17T12:05:28.902806919Z
2022-03-17T12:05:28.905552036Z
2022-03-17T12:05:28.907594864Z
2022-03-17T12:05:28.908563238Z
2022-03-17T12:05:28.909433758Z
2022-03-17T12:05:28.910549552Z
2022-03-17T12:05:28.911642330Z
2022-03-17T12:05:28.912596098Z
2022-03-17T12:05:28.913575587Z
2022-03-17T12:05:28.914538184Z
5
  • After so many years wondering if eventually I could just "portably" print a basic time stamp without forking some tool, you come along ;). What makes me wonder, as well, is why Chet Ramey has not yet implemented %N precision in bash.
    – ikaerom
    Commented Feb 3, 2023 at 18:01
  • 1
    @ikaerom, see edit for bash 5.0+ Commented Feb 3, 2023 at 18:40
  • Very cool! Thanks. It's going into my future scripts. Wouldn't t=$EPOCHREALTIME; TZ=UTC0 printf "%(%FT%T)T.${t#*.}Z\n" be sufficient? The second part "${t%.*}" is not needed anymore, right?
    – ikaerom
    Commented Feb 3, 2023 at 20:23
  • 1
    @ikaerom, with that printf would call time() again, so could give you the next second. For instance, $EPOCHREALTIME could expand to 1675456439.999996 and by the time printf is run, parses its arguments and calls time(), the current time will be a few dozens microsecond later, so the next second will have ticked and you'll get 2023-02-03T20:34:00.999996Z on output instead of 2023-02-03T20:33:59.999996Z Commented Feb 3, 2023 at 20:37
  • Thanks, mate. You're absolutely right. Haven't thought about this aspect. Sidenote: I remember you from back in the 90s on comp.unix.shell and other newsgroups. Together with Chris F.A. Johnson and Ted Timar, you consistently made the top-10 contributors list :). Clearly, this has not changed. What a pleasure!
    – ikaerom
    Commented Feb 4, 2023 at 7:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .