Update format.asciidoc to describe strict_date_optional_time_nanos (e…

…lastic#57527)

closes elastic#57019

docs/reference/mapping/params/format.asciidoc

@@ -66,10 +66,17 @@ The following tables lists all the defaults ISO formats supported:
 
 [[strict-date-time]]`date_optional_time` or `strict_date_optional_time`::
 
-    A generic ISO datetime parser where the date, in `year_month_day` format, is
-    mandatory and the time, separated by `T`, is optional.
+    A generic ISO datetime parser, where the date must include the year at a minimum, and the time
+    (separated by `T`), is optional.
     Examples: `yyyy-MM-dd'T'HH:mm:ss.SSSZ` or  `yyyy-MM-dd`.
 
+[[strict-date-time-nanos]]`strict_date_optional_time_nanos`::
+
+    A generic ISO datetime parser, where the date must include the year at a minimum, and the time
+    (separated by `T`), is optional. The fraction of a second
+    part has a nanosecond resolution.
+    Examples: `yyyy-MM-dd'T'HH:mm:ss.SSSSSSZ` or  `yyyy-MM-dd`.
+
 `basic_date`::
 
     A basic formatter for a full date as four digit year, two digit month of

docs/reference/mapping/types/date_nanos.asciidoc

@@ -24,7 +24,9 @@ This means that it will accept dates with optional timestamps, which conform
 to the formats supported by
 <<strict-date-time,`strict_date_optional_time`>> including up to nine second
 fractionals or milliseconds-since-the-epoch (thus losing precision on the
-nano second part).
+nano second part). Using <<strict-date-time,`strict_date_optional_time`>> will 
+format the result up to only three second fractionals. To
+print and parse up to nine digits of resolution, use <<strict-date-time-nanos,`strict_date_optional_time_nanos`>>.
 
 For instance:
 
@@ -98,4 +100,3 @@ same mapping parameters than with the `date` field can be used.
 
 Aggregations are still on millisecond resolution, even when using a `date_nanos`
 field. This limitation also affects <<transforms,{transforms}>>.
-