I'm wondering if the following date is ISO8601 compliant :
2012-03-02 14:57:05.456+0500
(for sure, 2012-03-02T14:57:05.456+0500 is compliant, but not that much human readable !)
IOW, is the T between date and time mandatory ?
It's required unless the "partners in information interchange" agree to omit it.
Quoting an earlier version of the ISO 8601 standard, section 4.3.2:
The character [T] shall be used as time designator to indicate the
start of the representation of the time of day component in these
expressions. [...]
NOTE By mutual agreement of the partners in information interchange,
the character [T] may be omitted in applications where there is no
risk of confusing a date and time of day representation with others
defined in this International Standard.
Omitting it is fairly common, but leaving it in is advisable if the representation is meant to be machine-readable and you don't have a clear agreement that you can omit it.
But according to Wikipedia:
In ISO 8601:2004 it was permitted to omit the "T" character by mutual agreement as in "200704051430", but this provision was removed in ISO 8601-1:2019. Separating date and time parts with other characters such as space is not allowed in ISO 8601, but allowed in its profile RFC 3339.
UPDATE : Mark Amery's comment makes a good point, that permission to omit the [T] does not necessarily imply permission to replace it with a space. So this:
2012-03-02T14:57:05.456+0500
is clearly compliant, and this:
2012-03-0214:57:05.456+0500
was permitted by earlier versions of the standard if the partners agreed to omit the T, but this:
2012-03-02 14:57:05.456+0500
apparently is not (though it's much more readable than the version with the T simply omitted).
Personally, if ISO 8601 compliance were required, I'd include the T, and if it weren't then I'd use a space (or a hyphen if it's going to be part of a file name).
See also RFC 3339 section 5.6, mentioned in Charles Burns's answer.
That date is not ISO-8601 compliant as Keith Thompson indicated, but it is compliant with RFC 3339, a profile of ISO 8601.
Sort of. See NOTE at the bottom of the following text from RFC 3339:
date-time = full-date "T" full-time
NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this
syntax may alternatively be lower case "t" or "z" respectively.
This date/time format may be used in some environments or contexts
that distinguish between the upper- and lower-case letters 'A'-'Z'
and 'a'-'z' (e.g. XML). Specifications that use this format in
such environments MAY further limit the date/time syntax so that
the letters 'T' and 'Z' used in the date/time syntax must always
be upper case. Applications that generate this format SHOULD use
upper case letters.
NOTE: ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.
Related
I am trying to pull some data from Twitter, and the date format is "YYYY-mm-DDTHH:MM". What does T mean in "YYYY-mm-DDTHH:MM"?
The T isn't substituted for a value, it's a character used in the output to designate that the second part is a Time.
For example: 2021-04-20T13:03
The format is part of the ISO 8601 international standard.
In the documentation for date/time type in Postgres, it says:
ISO 8601 specifies the use of uppercase letter T to separate the date and time. PostgreSQL accepts that format on input, but on output it uses a space rather than T, as shown above. This is for readability and for consistency with RFC 3339 as well as some other database systems.
However, I cannot find that part in RFC3339.
Can anybody help me?
Section 5.6
date-time = full-date "T" full-time
NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this
syntax may alternatively be lower case "t" or "z" respectively.
This date/time format may be used in some environments or contexts
that distinguish between the upper- and lower-case letters 'A'-'Z'
and 'a'-'z' (e.g. XML). Specifications that use this format in
such environments MAY further limit the date/time syntax so that
the letters 'T' and 'Z' used in the date/time syntax must always
be upper case. Applications that generate this format SHOULD use
upper case letters.
NOTE: ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.
What standard called for the use of HH:mm as the 24-hour clock whereas hh:mm is the 12-hour clock?
Likewise, I also often see dates noted as MM/dd/yyyy where MM is in caps to distinguish it from mm which indicates minutes.
Does anyone know what standard this nomenclature is based upon?
Probably you refer to the CLDR project which has defined the LDML standard. LDML means: "Locale Data Markup Language" and is listed as "Unicode Technical Standard #35", see also the title of the linked document:
http://www.unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table
However, you have not told exactly which language or library you use. Be aware of subtile differences. For example in Java, the old class SimpleDateFormat has exceptionally used the pattern symbol "u" as "Day number of week" while CLDR (and the newer class DateTimeFormatter) really interpretes "u" as "extended year (without era)".
By the way, I would never use "hh:mm" without "a" (as marker for am/pm in English speaking countries) or "B" for day periods (if your library supports it) because otherwise the 12-hour-clock is ambivalent.
I’m considering using uuid to differentiate my swift app, and looked around online for how to achieve it. While searching, I often found people lowercase the uuid such as:
let uuid = NSUUID().UUIDString.lowercaseString
Wouldn’t lowercasing the uuid be unnecessary or make it less random?
It is not less random, because UUIDs are not case-sensitive. UUIDs are 128-bit numbers, and in string form they are represented using hexadecimal digits. ‘A’ and ‘a’ are the same digit.
Standards such as ITU-T X.667 and RFC 4122 require them to be formatted using lower-case letters, but also require parsers to accept upper-case letters.
The NSUUID class and UUID struct use upper-case letters when formatting. Long ago, someone either got it wrong, or made the decision before the choice of lower-case letters was standardized. Apple won't change it now because doing so could break existing code that relies on the use of upper-case letters.
On Apple platforms, the UUID formatting code, unparse.c, is written in C, and (according to the copyright) was originally written by Theodore T'so in 1996 or 1997. But the code uses upper-case letters because UUID_UNPARSE_DEFAULT_UPPER is defined in uuid-config.h.
Because it is required by international standards
You may find the information here
6.5.4 Software generating the hexadecimal representation of a UUID shall not use upper case letters.
NOTE – It is recommended that the hexadecimal representation used in all human-readable formats be restricted to lower-case
letters.
The naming conventions for variable names are to be lower case (even for acronyms):
using uppercase for types (and protocols), lowercase for everything else
Here is a Swift programming style guide for reference:
https://github.com/raywenderlich/swift-style-guide
It also refers to the following Swift API Design guide:
https://swift.org/documentation/api-design-guidelines/
http://en.wikipedia.org/wiki/ISO_8601#Durations
It's not clear what the most correct representation of zero in ISO 8601 durations is.
Possible candidates:
PT0S
This site:
http://www.ostyn.com/standards/scorm/samples/ISOTimeForSCORM.htm
says
PT0H0M0S
Or probably the simplest is
P
But what is most correct? Is there a canonical zero duration representation?
The single letter "P" is certainly wrong because at least one duration element must be present.
The SCORM-specification requires "PT0H0M0S" only because of backwards compatibility with earlier SCORM-Versions, not because ISO mandates it. Citation from the link you have given:
the SCORM 2004 1.3.1 conformance test suite was coded to require the PT0H0M0S format for the initial zero value of the total attempt
time; using that format is therefore recommended where compatibility
with early implementations of SCORM 2004 is required.
So if you don't use SCORM then the expression "PT0S" is completely sufficient. However, I don't remember any location in the original ISO-8601-paper where they have specified how a zero duration has to look like. On the contrary, ISO-8601 also describes alternative duration formats like "P0000-00-00T00:00".
There is not only one single canonical representation if we interprete the word "canonical" as "conform with ISO-8601".
Update (after looking in the original ISO-paper):
ISO-8601 mandates at least one element for a zero duration (4.4.3.2.c - page 21):
If the number of years, months, days, hours, minutes or seconds in any
of these expressions equals zero, the number and the corresponding
designator may be absent; however, at least one number and its
designator shall be present.
Paragraph 4.4.3.3 says:
The complete representation of the expression for duration in the
alternative format is as follows:
Basic format: PYYYYMMDDThhmmss or PYYYYDDDThhmmss
Extended format: PYYYY-MM-DDThh:mm:ss or PYYYY-DDDThh:mm:ss
Keep also in mind that not every software is capable of supporting all format variations.