Update 0000-timestamp-offset-and-docs.md

Author: ccoffin

rfds/0000-timestamp-offset-and-docs.md

@@ -66,7 +66,10 @@ The agreed upon timezone format for timestamp fields in CVE Record Format:
 
 Note that a CVE producer can provide a timestamp in the form 
 yyyy-MM-ddTHH:mm:ss.sss without a timezone offset being specified. This will 
-be converted to UTC on submission to CVE Services.
+be converted to UTC on submission to CVE Services. Also note that a CVE 
+producer can provide a timestamp without milliseconds, and this will be 
+converted to include a milliseconds value with all zeros (e.g., 
+yyyy-MM-ddTHH:mm:ss will be converted to yyyy-MM-ddTHH:mm:ss.sssZ).
 
 Examples:
 - 2026-02-05T00:53:09.778Z
@@ -129,14 +132,21 @@ complement that process going forward.
 ## Recommended Priority
 [recommended-priority]: #recommended-priority
 
-Low
+Medium - This update should be considered a medium priority because as part of 
+the AWG data normalization efforts, a timezone offset that is out of range 
+(more than 23 hours) will currently pass schema validation but fail CVE 
+Services validation. The schema validation does not enforce acceptable values 
+for the timezone offset.
 
 ## Unresolved Questions
 [unresolved-questions]: #unresolved-questions
 
 Can a regular expression be defined that properly limits the timezone offset to 
 the valid range of values? I believe the answer is yes, but have not tried yet.
 
+The current timestamp regular expression does not require milliseconds. 
+Should we require milliseconds as part of the schema validation.
+
 Should we consider requiring a timezone offset be provided for all timestamp 
 fields in the future? In other words, should validation fail without it? 
 
@@ -150,3 +160,4 @@ timezone offset (outside of the range -12:00 through 14:00)?
 TBD
 
 
+