OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: Timestamps, yet again


The more I thought about this the more my thinking was driven by what various datetime libraries allow the developer to do.  While in a perfect world I’d prefer the ISO 8601 “just specify what you know” (which allows 2016-01-01 for example to say January 1, 2016), libraries that support 8601 don’t seem to give the developer any way of distinguishing between “2016-01-01” and “2016-01-01T00:00:00.0Z”.  Therefore, we’re better off going with RFC 3339 which mandates a full date/time and the separate precision specifier we’ve previously discussed.  As far as fractional seconds, I say we allow zero or more digits – the libraries support that, it’s compliant with RFC 3339 and at the F2F no one could articulate a reason why that was a burden to implementers.

 

So, in summary:

                RFC 3339

                All times expressed in UTC (“Z”)

                Separate precision specifier

 

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Monday, January 18, 2016 10:58 AM
To: cti@lists.oasis-open.org
Subject: [cti] Re: Timestamps, yet again

 

Thoughts???  We really need to decide this.  This along with IDs are the next major things we need to resolve and resolve SOON.  

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Jan 14, 2016, at 22:19, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:

 

As this issue was brought up at the Face2Face, and thus reopened for debate and consensus, and the consensus today was leaning toward the use of RFC3339 as is, without further stipulation and the removal of timestamp_precision field, I thought it would be best to re-read the RFC for clarification.  

 

Section 4.2. Local Offsets

Allows for local time, so long as it is an offset from UTC

 

5.8. Examples

1996-12-19T16:39:57-08:00

 

 

I do not see anything in RFC3339 that allows for dates/times with less precision than a fully qualified timestamp:  yyyymmddThh:mm:ssZ

 

ISO8601 does explicitly allow for reduced precision by just truncating the value.

 

 

From my understanding of the community we have the following requirements:

1) Represent reduced precision

            2015Z

            201501Z

            20150114Z

            20150114T23Z

            20150114T23:21Z

            20150114T23:21:20Z

            20150114T23:21:20.1Z

            20150114T23:21:20.12Z

            20150114T23:21:20.123Z

            etc.

2) Represent an arbitrary number of fractional sections

            20150114T23:21:20.1Z

            20150114T23:21:20.12Z

            20150114T23:21:20.123Z

            etc.

3) Represent values in local time as a offset to UTC or in UTC 

            20150114T23:21:20.123456Z

            20150114T23:21:20.123456-08:00

 

 

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]