On 06/09/2016 19:11, Salz, Rich wrote: > > I am thinking of standardizing the syntax for dates, times, and > durations used by the applications in the next releases, based on > http://www.w3schools.com/xml/schema_dtypes_date.asp (with the > extension that lowercase letters can also be used). > > Objects that need dates (x509 etc) will have a standard ?start flag. > It takes an ISO date-time, the time defaulting to 00:00. A time and > duration can be specified by putting /duration after the start date. > Or the abosolute time can be specified with an ?end flag. For example > > -start 2017-02-10/p30d > > -start 2017-02-10 ?end 2017-03-12 > > Both mean the same thing, from Feb 10 for 30 days. > > Comments? > > Please don't break compatibility with any command lines that may have been embedded into thousands of scripts around the world. So if a date/time/period string was acceptable to the old code, it should remain acceptable to the new code. This does not preclude unifying the parser code and rules, it simply means that the established syntax forms need to be accepted and take priority over any new forms added where the same string could have different meanings. Another related (long standing) issue is the inability to state an "as of" date to the various commands and APIs that validate signatures, certificates etc. Both past and future dates can be needed in various use cases. For any date related code, do not limit to the timespan of the system (or POSIX) time_t type. This would fail for long- duration root certificates, long-duration Android code signing certificates and for fields that specify dates other than certificate validity (such as date of birth or date of foundation for company/organizational entities). As test cases, try encoding the foundation date of e.g. the country China (not its current regime, but the country itself) or the religious organization commonly referred to as the Roman Catholic Church. Similarly, try encoding various future dates listed in documents such as the various Climate related treaties (though those would be less likely to appear in certificates). And of cause, never confuse the PKIX profile with the ITU-T standards. For example, PKIX limits some data fields to 1s precision while the standards do not. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
