"duration" can mean many things in your example of SLA.
let's continue on your SLA example and since other comment mentioned 620 API, let's continue and try to conclude the response.
In TMF620, the SLA could be modelled as such:
define the SLA itself as a product offering. this defines the prices, the SLA specification, the SLA terms.
In TMF APIs you have:
Absolute duration (bounded by dates) and often called "validFor" in TMF API
- When the term is available to sell. This indicates the start and end date of the term lifecycle in the catalogue. If you buy the product before 1st of July, this is the term that will apply. from 1st of July, there will be another term, or no term.
- TMF API use validFor{} object
- Type: absolute time range (start/end datetimes).
- Example: startDateTime: 01/01/2025, endDateTime: 30/06/2025. (also 6 months)
Relative duration (elapsed time or interval length)
- how long the commitment applies once the customer activates it (by purchasing the product offering).
- TMF API use
duration{} object
- Type: relative length (amount+units).
- example:
productOfferingTerm.duration= 12 months.
the SLA duration.
- works like Relative duration but expressed in ISO 8601
- the word "duration" could be avoided, suggest to call it "Response Time"
- response time should be modelled as a product characteristic.
- This means that SLA etc are first defined as a product offering.
- Type: ISO 8601
- example: PT1H
Here is an extract from product catalogue that illustrates all 3 concepts:
{
"@type": "ProductOffering",
"id": "PO-Support",
"name": "Support Service",
"validFor": { // 1st concept of duration
"startDateTime": "2025-09-01T00:00:00Z",
"endDateTime": "2025-12-31T23:59:59Z"
},
"productOfferingTerm": [
{
"id": "term-12m",
"name": "12-month contract",
"duration": { "amount": 12, "units": "month" } // 2nd concept of duration
}
],
"productSpecification": {
"id": "PS-Support",
"name": "Support SLA Spec",
"productSpecCharacteristic": [
{
"id": "respTarget",
"name": "ResponseTimeTarget",
"valueType": "duration", // This characteristic holds an ISO-8601 duration value
"productSpecCharacteristicValue": [ // 3rd concept of duration
{ "value": "PT24H" }, // 24 hour-response time for Gold
{ "value": "PT48H" } // 48 hour-response time for Silver
]
},
{
"id": "hoursPolicy",
"name": "HoursPolicy",
"valueType": "string",
"productSpecCharacteristicValue": [
{ "value": "business" }
]
}
]
}
}
my 3 cents.
------------------------------
Kind regards,
Matthieu Hattab
Digital Sales Domain Architect
Lyse Tele AS
------------------------------
Original Message:
Sent: Sep 11, 2025 15:28
From: Chirag Raval
Subject: Time Duration Units in API Responses - Best Practice for Hour Representation?
Here's a summary of TM Forum's approach to handling durations across APIs, especially in contexts like SLA timeframes, service availability, and validity periods:
Does TMF recommend a standardized representation for durations?
Yes - TMF APIs generally recommend using ISO 8601 duration format, such as PT48H for 48 hours. This format is:
Unambiguous and internationally recognized.
Machine-readable and supported by many libraries.
Consistent with other time-related fields like validFor, startDateTime, and endDateTime.
However, some TMF API implementations and discussions acknowledge that ISO 8601 durations (especially the Pxx format) can be poorly supported in some runtimes, leading to occasional use of simpler formats like integer hours 1.
Examples from TMF APIs
✅ TMF620 – Product Offering
Uses the validFor field to define validity periods for offerings.
validFor is typically a TimePeriod object with startDateTime and endDateTime in ISO 8601 format.
This is used to control lifecycle states like Launched, Pre-sales, etc., based on time 1.
✅ TMF623 – SLA Management
Defines SLA lifecycle operations including negotiation, activation, enforcement, and violation handling.
Duration-related fields (e.g., response time, resolution time) are expected to be expressed in ISO 8601 format for consistency 2.
Stick with ISO 8601 (PT48H, P2D, etc.) even for simple durations.
Clearly document the expected format in your API specs and payload examples.
Use validation libraries that support ISO 8601 parsing to avoid runtime issues.
------------------------------
Chirag Raval
Lead Consultant
Infosys
Original Message:
Sent: Jul 27, 2025 07:05
From: Jhonn Marie
Subject: Time Duration Units in API Responses - Best Practice for Hour Representation?
Hi all,
I'm currently working on integrating several TMF APIs where "duration" (e.g., service duration, SLA timeframes, etc.) needs to be handled across systems. Some upstream systems use ISO 8601 durations, while others use simple integer hour values ("48" to mean 48 hours).
I'm wondering:
- Does TMF recommend a standardized representation for time durations in hours?
- Should APIs stick with ISO 8601 format (e.g. PT48H) even for simple hourly durations?
- Are there known TMF Open API specs that already address this?
I'd appreciate examples from TMF APIs that deal with service availability, response time, or validity periods, if anyone has pointers.
Thanks in advance for your help!
Jhonn Marie
#General
------------------------------
Jhonn Marie
TO BE VERIFIED
------------------------------