Here I hope to make it easier for people to find an authoritative definition for the meaning of an ISO 8601 profile. To be clear, this doesn't mean the definition itself will be simple or clear. Sorry.
I was able to find the document below by way of this English Language & Usage StackExchange post: What does it mean for RFC 3339 to be “a profile of” ISO 8601?
You need to read ISO 8601, in particular ISO/WD 8601-2 Annex B, where the term "profile" is defined. It's not a regular English meaning; rather it's tech standards jargon. – Mark Beadles Jul 8 '19 at 21:53
Below, I've created a Markdown version of Annex B from the mentioned document. The original PDF is here: https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_iso_wd_8601-2_2016-02-16.pdf
Annex B (normative)
ISO 8601 profiles
This is an excerpt from:
https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_iso_wd_8601-2_2016-02-16.pdf
B.1 Statement of the problem
ISO 8601 includes many features, and, in many cases, several different formats to represent a single feature. Two vendors implementing 8601 may implement different features, or different representations of a given feature, and their products might not interoperate. Moreover, some features have more than one interpretation and different vendors might select different interpretation, making interoperability even less likely. 8601 does not provide guidelines to address these concerns, levels of support, or conformance requirements. Each vendor is left to decide for itself what features, representation, and interpretations to implement.
B.1.1 Some historical background
The W3C defined date and time formats to begin to address these concerns: http://www.w3.org/TR/xmlschema-2/#isoformats. These formats are based on 8601, and they have proved invaluable for the interoperability of Web data. These formats have their roots in what we call a “profile” of ISO 8601: Date and Time Formats. http://www.w3.org/TR/NOTE-datetime which states
The W3C Note, submitted in 1997 by Reuters, was never endorsed by the W3C, but it did provide the original impetus for the development of the very useful and successful W3C date and time formats.
B.1.2 Generalizing the concept of an ISO 8601 profile
This document attempts to expand and generalize the concept of an ISO 8601 Profile.
A Profile of ISO 8601 is a specification developed by a particular community which explains how ISO 8601 is to be used, to carry out a particular function or group of functions relevant to that community.
It may list features of 8601 to be supported.
In cases where there are multiple methods specified in 8601 to support a particular function, the profile may select a single method.
In cases where there are different interpretations of a particular function, the profile may select a single interpretation, or provide clarification.
It might list features that are not relevant and need not be supported.
It might specify several levels of support.
At minimum, a profile should state what an implementer must implement in order to claim conformance to the profile. If there are multiple levels specified, it should state conformance requirements for each level.
Different communities may define different profiles. In fact any given community may define multiple profiles. “Community” is used loosely to mean a group with a common interest in 8601. It is not intended that 8601 profiles be approved by any formal body; any person or community can develop a profile. There should however be a unique name for every profile so that it may be referenced. The registration agency for ISO 8601 should register profiles upon request, and help to assure uniqueness of names. It is hoped that there will be mechanisms developed to provide interoperability between profiles however that is beyond the scope of this document.
This document provides one (draft) profile (section 2), and it is expected that additional profiles will be developed.
B.1.3 Multiple profiles
A product may implement several profiles. Here we distinguish between static support and dynamic operation.
B.1.3.1 Static Support
Suppose profile X specifies features A, B, and C, and excludes feature D. If a product claims to support profile X that does not mean that it cannot support feature D. A different profile – profile Y – might specify features C, D, and E. And there is not, nor should there be, anything inherent in the profile concept that would preclude a product from supporting as many profiles as it chooses to support.
B.1.3.2 Dynamic Operation
On the other hand suppose there are two communication parties, P1 and P2, exchanging ISO 8601 data. P1 uses a product that supports profile X (only) while P2 uses a product that supports profiles X and Y. In order for P1 and P2 to interoperate they must operate under profile X, because it is the only profile in common supported. (Thus P2 must be able to suppress features excluded by P1.)
The process by which two communicating parties agree to operate according to a particular profile is a complex area which needs further study. It is not fully addressed by this document and is to a certain extend outside the scope of this document. Three possible approaches:
Specified by Protocol. The exchange of ISO 8601 data might be done under the control of a protocol, which could be used to negotiate a particular profile. (8601 itself is a data format, not a protocol, and could not be adapted to accomplish this task.)
Specified by Format.Two parties might be exchanging data of a certain type, for example bibliographic data. The definition of the bibliographic format could specify that date/time data conform to a specific profile.
Specified by datatype. For exchange of date serialized into XML, or RDF (any RDF serialization), date and time data can carry its datatype, for example xs:date, which, as noted above, corresponds to the W3C profile.