Investigation of different time formats used in BoB-specification and documentation

Where are time notations mentioned?

The sum of different time stamp indications throughout the documentation: 

Subject / LocationTime fields (documentation)Time fields (examples)

MTS1 version 1.6.0

page 6:

exp  – Signature Expiry (timestamp in ISO 8601 basic format, string)
nbf  – Signature Inception (timestamp in ISO 8601 basic format, string)

pages 8-9:

– Current Time (timestamp in ISO 8601 basic format, string)

page 13:

"nbf": { "description": "Not valid before in ISO 8601 compact format",  "type": "string" },    
"exp": { "description": "Not valid after in ISO 8601 compact format",  "type": "string"},

page 16:

"t": {"description": "Current Time (timestamp in ISO 8601 basic format)","type": "string"}

t: “20151009T110310”

MTS2 version 1.0.1

N/AN/A

MTS3 Version 1.0.2

page 8:

"relativeValidity": {   "title": "Relative validity",   "description": "Time in ISO 8601:2004 format" }

page 10:

"timeOfIssue": {   "title": "Time of issue",   "description": "Time in ISO 8601:2004 format"}

N/A

MTS4 Version 1.1.0

page 4:

"notvalidbefore" : (string, ISO 8601 in basic format),  
"notvalidafter" : (string, ISO 8601 in basic format),

All timestamps SHALL be in UTC (Universal Co-ordinated Time), prepended with the “Z” designator for the zero UTC offset as specified in (ISO 8601:2004).

page 6-7:

"signatureLifetime": {"description": "Maximum signature life-time allowed for this PID (ISO 8601 period format)"}

N/A

MTS5 version 1.0.1

N/AN/A

MTS6 version 1.1.0

pages 6, 8:

Time intervals in ISO8601

@20070301T1300/20080511T1530
"_datetime":"20151102T1620"

MTS7 version 1.0.0

Appendix B, time: Current Time in ISO 8601 formatN/A

BoB Authentication API

nbf, iat, exp: integer($int64) title: Expiration time
NumericDate indicating end of claim validity

"exp": 1490001801,
"iat": 1489998201,

"nbf": 1489998201,

BoB Booking API

Booking: confirmBefore/confirmedWhen: unspecified
Ride: departureDateTime, arrivalDateTime: unspecified

"confirmBefore": "2018-10-22T15:19:13.880Z",
"confirmedWhen": "2018-10-22T15:19:13.880Z",

BoB Device API

iat: integer($int64) Issued at timestamp
exp: integer($int64) Expire timestamp

"exp": 1490002591,
"iat": 1489998991,

BoB Inspection API

Ticketevent, inspectionReport: time string($date-time) Time stamp in ISO 8601 format

Example request:   
"time": "2016-11-07T13:49:33.638462Z",

Example model inspectionevent:
time: 2018-10-22T11:31:15.210Z

BoB Participant Metadata API

N/AN/A

BoB Product API

validityPeriod: string Validity period in ISO 8601 duration format
manifestExpire: string($date-time) Expire date-time for manifest

"productExpire": "2017-03-20T15:51:11+00:00”

BoB Ticket API

startOfValidity: Request start of validity set in the future (must be within the validity time of the manifest). Time stamp in ISO 8601 format. string (date-time)
issuedAt: Time stamp in ISO 8601 format string (date-time)
time: Time stamp in ISO 8601 format string (date-time)

"issuedAt": "2018-10-22T15:18:10.023Z",
"issuedAt" : "20170203T123400Z",
"time": "2018-10-22T15:16:44.704Z",


BoB Token API

expire: string, Expire time stamp in ISO 8601 format"expire": "1985-04-12T23:20:50.52Z"

BoB Validation API

time: string($date-time) Time stamp in ISO 8601 format
expire: string($date-time) Expire time stamp in ISO 8601 format

"time": "2016-11-07T13:49:33.638462Z",  
"time": "20161224T140000Z",
"expire": "19730614T000000Z"
Wiki: How does it workTicket information, ISO 8601 Basic@P7M/20160618T0000
Wiki: API ExamplesSubmit validation event, ISO 8601 Extended'time': '2016-11-07T13:49:33.638462Z'
Wiki: MTB TestingPayload and response, ISO 8601 Basic"time": "20170503T120000Z"
"toi": "20170502T130747Z"

Which time notations do we use?

ISO8601

While ISO-8601 is a widely used time format, it isn't strictly defined which format should be used. Example valid formats include 2018-10-23, 2018-10-23T07:27:27+00:00, 2018-10-23T07:27:27Z, 20181023T072727Z, 2018-W43, 2018-W43-2, 2018-296.

For reduced accuracy, any number of values may be dropped from any of the date and time representations, but in the order from the least to the most significant. For example, "2004-05" is a valid ISO 8601 date, which indicates May (the fifth month) 2004. This format will never represent the 5th day of an unspecified month in 2004, nor will it represent a time-span extending from 2004 into 2005.

While current documentation only shows a few of the most used formats, all BoB implemetations should be able to handle for example 2018-W43-2T102800. This is most likely not the case, therefore this standard is too broad to be used in the documentation.

Unix/Epoch timestamps

This is a simple, non-ambiguous format in which every datetime is represented by the number of seconds since 1970-01-01, in UTC. Leap seconds are not counted. It is a compact and easy to use format, but might cause problems around 2038. Implementations should take care of this by storing the data in a proper format, for example unsigned 32-bit integers or signed 64-bit integers,

On systems where the representation of Unix time is as a signed 32-bit number, the representation will end after the completion of 2147483647 (231 − 1) seconds from 00:00:00 on 1 January 1970, which will happen at 3:14:08 on 19 January 2038 UTC