ISO 13209-3:2012

INTERNATIONAL ISO
STANDARD 13209-3
First edition
2012-08-15
Road vehicles — Open Test sequence
eXchange format (OTX) —
Part 3:
Standard extensions and requirements
Véhicules routiers — Format public d'échange de séquence-tests
(OTX) —
Partie 3: Exigences et spécifications des extensions du standard

Reference number
©
ISO 2012
©  ISO 2012
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2012 – All rights reserved

Contents Page
Foreword . vi
Introduction . vii
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated terms . 2
4 Requirements . 3
4.1 Basic principles for requirements definition . 3
4.2 Requirement priorities . 3
4.3 Requirement listing . 4
5 Extension overview . 7
5.1 General . 7
5.2 Dependencies . 7
5.3 Basic characteristics of the OTX extensions . 8
6 OTX DateTime extension . 10
6.1 Introduction . 10
6.2 Terms . 10
7 OTX DiagCom extension . 13
7.1 Introduction . 13
7.2 General considerations . 13
7.3 Data types. 21
7.4 Exceptions . 24
7.5 Variable access . 26
7.6 Actions. 27
7.7 Terms . 42
8 OTX DiagDataBrowsing extension . 67
8.1 Introduction . 67
8.2 Data types. 67
8.3 Variable access . 69
8.4 Terms . 69
9 OTX EventHandling extension . 74
9.1 Introduction . 74
9.2 Data types. 74
9.3 Variable access . 76
9.4 Actions. 76
9.5 Terms . 78
10 OTX Flash extension . 85
10.1 Introduction . 85
10.2 Data types. 86
10.3 Exceptions . 88
10.4 Variable access . 89
10.5 Actions. 89
10.6 Terms . 92
11 OTX HMI extension . 113
11.1 Introduction . 113
11.2 Data types . 116
11.3 Exceptions . 118
11.4 Variable access . 119
11.5 Actions . 119
11.6 Terms . 130
11.7 Signatures . 134
12 OTX i18n extension. 137
12.1 Introduction . 137
12.2 Data types . 137
12.3 Exceptions . 138
12.4 Variable access . 139
12.5 Terms . 139
13 OTX Job extension . 147
13.1 Introduction . 147
13.2 Exceptions . 147
13.3 Actions . 148
13.4 Terms . 153
13.5 Standard signature definitions . 157
14 OTX Logging extension . 160
14.1 Introduction . 160
14.2 Data types . 161
14.3 Variable access . 162
14.4 Actions . 163
14.5 Terms . 165
15 OTX Math extension . 167
15.1 Introduction . 167
15.2 Terms . 167
16 OTX Measure extension . 170
16.1 Introduction . 170
16.2 Data types . 170
16.3 Exceptions . 171
16.4 Variable access . 172
16.5 Signatures . 172
16.6 Actions . 175
16.7 Terms . 177
17 OTX Quantities extension . 183
17.1 Introduction . 183
17.2 Data types . 185
17.3 Exceptions . 187
17.4 Variable access . 188
17.5 Terms . 188
18 OTX StringUtil extension . 196
18.1 Introduction . 196
18.2 Data types . 196
18.3 Exceptions . 197
18.4 Variable access . 198
18.5 Terms . 198
Annex A (normative) Comprehensive checker rule listing . 205
Annex B (normative) OTX DiagCom extension data type mappings . 208
Annex C (normative) OTX DiagMetaData auxiliary for the OTX DiagCom extension . 210
Annex D (normative) OTX standard signature documents . 214
Annex E (informative) Test sequence examples . 215
Annex F (informative) OTX DiagComRaw extension for resource-restrained systems . 218
iv © ISO 2012 – All rights reserved

Annex G (normative) XML Schemas . 231
Bibliography . 278

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 13209-3 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronic equipment.
ISO 13209 consists of the following parts, under the general title Road vehicles — Open Test sequence
eXchange format (OTX):
 Part 1: General information and use cases
 Part 2: Core data model specification and requirements
 Part 3: Standard extensions and requirements
vi © ISO 2012 – All rights reserved

Introduction
Diagnostic test sequences are utilized whenever automotive components or functions with diagnostic abilities
are being diagnosed, tested, reprogrammed or initialised by off-board test equipment. Test sequences define
the succession of interactions between the user (i.e. workshop or assembly line staff), the diagnostic
application (the test equipment) and the vehicle communication interface as well as any calculations and
decisions that have to be carried out. Test sequences provide a means to define interactive, guided
diagnostics or similar test logic.
Today, the automotive industry mainly relies on paper documentation and/or proprietary authoring environ-
ments to document and to implement such test sequences for a specific test application. An author who is
setting up engineering, assembly line or service diagnostic test applications needs to implement the required
test sequences manually, supported by non-uniform test sequence documentation, most likely using different
authoring applications and formats for each specific test application. This redundant effort can be greatly
reduced if processes and tools support the OTX concept.
ISO 13209 proposes an open and standardized format for the human- and machine-readable description of
diagnostic test sequences. The format supports the requirements of transferring diagnostic test sequence
logic uniformly between electronic system suppliers, vehicle manufacturers and service dealerships/repair
shops.
ISO 13209-2 represents the requirements and technical specification for the fundament of the OTX format,
namely the "OTX Core". The Core describes the basic structure underlying every OTX document. This
comprises detailed data model definitions of all required control structures by which test sequence logic is
described, but also definitions of the outer, enveloping document structure in which test sequence logic is
embedded. To achieve extensibility the core also contains well-defined extension points that allow a separate
definition of additional OTX features – without the need to change the core data model.
This part of ISO 13209 extends the Core by a set of additional features, using the extension mechanism rules
described in ISO 13209-2. The extensions defined herein comprise features which allow diagnostic
communication to a vehicle's diagnostic interface, flashing, executing diagnostic jobs, controlling
measurement equipment, internationalisation, working with physical units, accessing the environment,
communication via a human machine interface (HMI) and other utility extensions.

INTERNATIONAL STANDARD ISO 13209-3:2012(E)

Road vehicles — Open Test sequence eXchange format
(OTX) —
Part 3:
Standard extensions and requirements
1 Scope
This part of ISO 13209 defines the Open Test sequence eXchange (OTX) extension requirements and data
model specifications.
The requirements are derived from the use cases described in ISO 13209-1. They are listed in Clause 4.
The data model specification aims at an exhaustive definition of all features of the OTX extensions which have
been implemented to satisfy the requirements. This part of ISO 13209 establishes rules for the syntactical
entities of each extension. Each of these syntactical entities is accompanied by semantic rules which
determine how OTX documents containing extension features are to be interpreted. The syntax rules are
provided by UML class diagrams and XML schemas, whereas the semantics are given by UML activity
diagrams and prose definitions.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 646:1991, Information technology — ISO 7-bit coded character set for information interchange
ISO 8601:2004, Data elements and interchange formats — Information interchange — Representation of
dates and times
ISO/IEC 8859-1:1998, Information technology — 8-bit single-byte coded graphic character sets — Part 1:
Latin alphabet No. 1
ISO/IEC 10646, Information technology — Universal Multiple-Octet Coded Character Set (UCS)
ISO/IEC 13209-1, Road vehicles — Open Test sequence eXchange format (OTX) — Part 1: General
information and use cases
ISO/IEC 13209-2, Road vehicles — Open Test sequence eXchange format (OTX) — Part 2: Core data model
specification and requirements
ISO/IEC 19501:2005, Information technology — Open Distributed Processing — Unified Modeling Language
(UML) Version 1.4.2
ISO 14229 (all parts), Road vehicles — Unified diagnostic services (UDS)
ISO 22900 (all parts), Road vehicles — Modular vehicle communication interface (MVCI)
ISO 22901 (all parts), Road vehicles — Open diagnostic data exchange (ODX)
RFC 1866, Hypertext Markup Language - 2.0
SAE J1979, E/E Diagnostic Test Modes
W3C XPtr:2003, W3C Recommendation: XPointer Framework (all parts)
W3C XLink:2001, W3C Recommendation: XML Linking Language (XLink) Version 1.0
W3C XML:2008, W3C Recommendation: Extensible Markup Language (XML) 1.0 (Fifth Edition)
W3C XMLNS:2009, W3C Recommendation: Namespaces in XML 1.0 (Third Edition)
W3C XSD:2004, W3C Recommendation: XML Schema (all parts)
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 13209-1, ISO 13209-2 and the
following apply.
3.1.1
custom screen
screen with attributes and fields defined by a test sequence author
3.1.2
dialog
screen with predefined attributes and fields which can be set or read from an OTX sequence
3.1.3
ECOS measurement device
widely-used embedded system for testing electrical consumer's current and voltage curves
3.1.4
modal dialog
dialog which is blocking the flow execution until the user dismisses it
3.1.5
non-modal screen
asynchronous, non-blocking screen which is still displayed while the test sequence execution continues
3.1.6
tester
computer system attached to a vehicle via a Vehicle Communication Interface, running a diagnostic
application
3.1.7
text ID
string reference to a thesaurus data base entry containing localized string translations
3.2 Abbreviated terms
API Application Programming Interface
DTC Diagnostic Trouble Code
2 © ISO 2012 – All rights reserved

ECOS Electric Check-Out System
ECU Electronic Control Unit
GUI Graphical User Interface
HMI Human Machine Interface
IFD Interface Definition (OTX extension)
NOP No Operation Performed
OEM Original Equipment Manufacturer
OTX Open Test sequence eXchange
PDU Protocol Data Unit
UI User Interface
UML Unified Modeling Language
VCI Vehicle Communication Interface
XML Extensible Markup Language
XSD XML Schema Definition
4 Requirements
4.1 Basic principles for requirements definition
Basic principles have been established as a guideline to define the OTX requirements:
a) OTX requirements specify the conditions that the OTX data model and format shall satisfy.
b) All stakeholders (System Suppliers, OEMs, Tool Suppliers), which offer diagnostic test procedures are
expected to implement and follow the requirements of this standard.
The content of OTX documents and the quality of the information is the responsibility of the originator.
4.2 Requirement priorities
Each of the following requirements carries a priority-attribute which can be set to SHALL or SHOULD.
 SHALL:
The requirement represents stakeholder-defined characteristics the absence of which will result in a
deficiency that cannot be compensated by other means.
 SHOULD:
If the requirement defined characteristic is not or not fully implemented in the data model, it does not
result in a deficiency, because other features in the data model can be used to circumvent this.
4.3 Requirement listing
Extensions_R01 – Read current date and time
Priority: SHALL
Rationale: It shall be possible to retrieve the current date and time.
Description: The current date and time shall be accessible in a way appropriate for calculating durations
between two dates but also for generating a human readable form of a date.
Extensions_R02 – Support but not require ODX
Priority: SHALL
Rationale: For communication with vehicle ECUs, the usage of ODX shall be supported but not forced.
Description: Any vehicle communication related extension data model shall match to a useful subset of the
functionality of ODX.
Extensions_R03 – Handle flash sessions
Priority: SHALL
Rationale: Functionality shall be provided to browse and select flash sessions.
Description: A extension for flashing shall provide the possibility to select by direction and name.
Extensions_R04 – Low level flash data access
Priority: SHALL
Rationale: Functionality shall be provided for browsing and selecting data from the flash environment
(download container).
Description: The data shall be clustered in blocks and segments. Security functions, used by modern data
formats like ODX Flash shall be supported.
Extensions _R05 – Flash data storage
Priority: SHALL
Rationale: Uploaded flash data shall be stored in local storage.
Description: For flash data upload, an OTX extension for flashing shall provide functionality to store in a
selected format.
Extensions _R06 – Enable developer to use OTX in place of ODX Java Jobs
Priority: SHALL
Rationale: Functionality shall be provided to emulate ODX Java Jobs by OTX sequences.
Description: A job extension shall enable developers to run OTX sequences as ODX Java Jobs.
SingelEcuJob, SecurityAccessJob and FlashJob shall be supported.
4 © ISO 2012 – All rights reserved

Extensions _R07 – Provide means for diagnostic communication with vehicle ECUs
Priority: SHALL
Rationale: Functionality shall be provided for diagnostic communication with a vehicle's ECU systems.
Description: There shall be an OTX extension which allows configuring and executing diagnostic services of
vehicle ECUs. It shall be possible establish a communication channel to a particular ECU, to configure request
parameters of a diagnostic service which is sent to the ECU and to analyze the response parameters of the
ECU. The description of communication channels, diagnostic services and parameters shall happen in a
human-readable and symbolic way; any existing diagnostic symbolic-to-binary mapping (e.g. ODX) shall be
supported. The actual functionality for sending a diagnostic service and receiving shall be provided through an
interface between test sequence and vehicle (e.g. MCD 3D API and MVCI).
Extensions _R08 – Provide means to browse diagnostic data
Priority: SHALL
Rationale: Functionality shall be provided to read information from the static diagnostic data base of a
diagnostic application.
Description: An OTX extension shall be provided which allows reading static information from a diagnostic
data base, like e.g. available communication channels, diagnostic services for a communication channel or
parameters for a diagnostic service.
Extensions _R09 – Enable developer to handle events
Priority: SHALL
Rationale: Functionality shall be provided which allows for an OTX test sequence to react on a well-defined
set of events.
Description: An OTX extension shall enable developers to configure a test sequence so that it can wait for
certain events to happen (e.g. when a timer expires, a variable value changes or user input is received from
the UI, etc.). There shall be a way to get further information about an event, e.g. what kind of event it is, and
additional information about a particular event.
Extensions _R10 – Provide means for human machine interface functionality
Priority: SHALL
Rationale: Functionality shall be provided which allows OTX test sequences to communicate with a user in a
bidirectional way.
Description: An OTX extension is required which allows sending and receiving information to and from a user
interface (e.g. a GUI window with input controls). The extension shall not provide means for explicitly
configuring the graphical layout of the information; instead it shall only provide a bidirectional interface for the
communicated data itself.
Extensions _R11 – Enable developer to configure localized test sequences
Priority: SHALL
Rationale: A test sequence developer shall be supported in configuring OTX test sequences which are
prepared for translation to different languages.
Description: An OTX extension is required which allows the developer to access a thesaurus data base via a
text ID concept. The developer shall be supported by functionality which translates text IDs into the language
configured for the runtime system or to other languages (as far as known by the runtime system). The
thesaurus data base itself shall not be part of the standard. A generic approach shall support different kinds of
thesaurus data bases.
Extensions _R12 – Provide means for logging
Priority: SHALL
Rationale: It shall be possible to write log messages to a logging resource.
Description: An OTX extension is required which allows writing log messages to a logging resource;
messages shall be filterable according to severity.
Extensions _R13 – Support measurement equipment
Priority: SHALL
Rationale: Measurement equipment in manufacturing and after sales workshops shall be accessible via
appropriate functionality.
Description: An OTX extension is required which allows receiving measurement values from measurement
equipment. There shall be an abstraction layer which allows using any kind of measurement equipment.
Extensions _R14 – Support physical units
Priority: SHALL
Rationale: Functionality is required which allows the handling of physical values with units
Description: An OTX extension is required which allows describing physical quantities. The extension shall
facilitate common calculations done on such physical quantities, like e.g. the transformation of a physical
value from one unit-system to another (e.g. representing a distance by kilometres or miles, etc.). It shall also
allow basic mathematical operations on quantities without requiring the developer to explicitly care for the unit
(e.g. it shall be possible to calculate 10 m + 2 km directly).
Extensions _R15 – Support for enhanced string operations
Priority: SHALL
Rationale: The OTX Core string operations shall be extended by additional commonly used string operations.
Description: An OTX extension is required which describes additional string operations which shall facilitate
calculations on string values.
Extensions _R16 – Support of basic mathematical functions
Priority: SHALL
Rationale: The arithmetic operations of the OTX Core shall be extended by additional mathematical functions.
Description: An OTX extension is required which describes a set of additional mathematical functions which
are needed in some diagnostic applications (like e.g. trigonometric and logarithmic functions, etc.).
6 © ISO 2012 – All rights reserved

5 Extension overview
5.1 General
This document represents the specification of the OTX standard extensions for data model version "1.0.0".
5.2 Dependencies
Figure 1 shows a UML package diagram [ISO/IEC 19501] describing the full set of OTX extensions (together
with the OTX Core) and the import dependencies in between them. OTX extensions use or extend types
defined in the OTX Core. Therefore, all of the extensions are (directly or indirectly) based on the OTX Core
data model, as specified by Part 2 of ISO 13209. Aside of the OTX Core, the OTX EventHandling,
OTX DiagCom and OTX Quantities extensions also play a central role; types defined there are used or
extended by other OTX extensions.

Figure 1 — Overview: OTX schema dependencies

IMPORTANT — The OTX Core is a prerequisite for any OTX application and shall always be fully
supported. By contrast, OTX applications are NOT required to support all of the extensions specified
in this standard. The set of supported extensions may vary depending on the field of application.
However, an OTX application supporting an extension which imports other extensions shall support
these, too. This guarantees that the set of supported extensions is consistent with regard to the
dependencies.
Figure 1 also shows the auxiliary packages OTX DiagMetaData as well as OTX AppInfo. These packages are
no OTX extensions; they support OTX authoring systems with additional data used only at authoring time. The
information is not required at runtime of an OTX test sequence. For the DiagMetaData auxiliary, please see
Annex C. For the AppInfo auxiliary, please refer to Part 2 of ISO 13209.
5.3 Basic characteristics of the OTX extensions
Table 1 provides an overview about all OTX extensions and their basic characteristics.
Table 1 — OTX extension characteristics
Extension (schema file) Summary Dependencies
DateTime
provides access to system time Core
(otxIFD_DateTime.xsd)
DiagCom
connecting to ECUs, creating and executing diagnostic EventHandling,
(otxIFD_DiagCom.xsd) services, analysing communication data Quantities, Core
DiagComRaw direct diagnostic communication on a non-symbolic (binary)
DiagCom
(otxIFD_DiagComRaw.xsd) level
DiagDataBrowsing browsing functionality for reading data from the diagnostic
DiagCom, Core
(otxIFD_DiagDataBrosing.xsd) data base
EventHandling
support for the OTX event handling mechanism. Core
(otxIFD_Event.xsd)
Flash
functionality for downloading and uploading flash data to and
DiagCom, Core
(otxIFD_Flash.xsd) from ECUs
HMI functionality for communicating with the UI (user interface),
EventHandling, Core
(otxIFD_HMI.xsd) through dialogs and screens
i18n internationalisation features, multi-language support and
Quantities, Core
(otxIFD_I18n.xsd) translation mechanisms
Job functionality for emulating ODX Java jobs by OTX test DiagCom, Quantities,
(otxIFD_Job.xsd) sequences Core
Logging
support for (Log4J-style) logging Core
(otxIFD_Logging.xsd)
Math
extended mathematical functions Core
(otxIFD_Math.xsd)
Measure executing measurement device services, measuring physical EventHandling
(otxIFD_Measure.xsd) values, analyzing measurements Quantities, Core
Quantities handling of quantity data, wrt. SI unit system, transformations
Core
(otxIFD_Quantities.xsd) between units, etc.
StringUtil
extended functionality for string handling Core
(otxIFD_StringUtil.xsd)
8 © ISO 2012 – All rights reserved

Table 2 shows the XSD namespace associations of all OTX extensions [W3C XSD] [W3C XMLNS]. Each
namespace has a prefix assigned to it. This applies also to the OTX Core namespace which has the
otx: prefix (not shown in the table). In the remainder of this document, the prefixes defined here are used to
mark types which belong to extensions other than the one which is currently described. In contrast, the types
defined by the currently described extension are not prefixed.
Table 2 — OTX extension namespace associations
Extension Namespace Prefix
http://iso.org/OTX/1.0.0/DateTime time:
DateTime
DiagCom http://iso.org/OTX/1.0.0/DiagCom diag:
http://iso.org/OTX/1.0.0/DiagComRaw raw:
DiagComRaw
http://iso.org/OTX/1.0.0/DiagDataBrowsing data:
DiagDataBrowsing
EventHandling http://iso.org/OTX/1.0.0/Event event:
Flash http://iso.org/OTX/1.0.0/Flash flash:
http://iso.org/OTX/1.0.0/HMI hmi:
HMI
http://iso.org/OTX/1.0.0/i18n i18n:
i18n
Job http://iso.org/OTX/1.0.0/Job job:
Logging http://iso.org/OTX/1.0.0/Logging log:
http://iso.org/OTX/1.0.0/Math math:
Math
http://iso.org/OTX/1.0.0/Measure measure:
Measure
Quantities http://iso.org/OTX/1.0.0/Quantities quant:
StringUtil http://iso.org/OTX/1.0.0/StringUtil string:

Please consider the example in Figure 2. It shows the IsDiagServiceEvent term from the OTX DiagCom
extension. The term accepts a parameter which is defined in the OTX EventHandling extension, therefore the
type of the element is marked with the event: prefix (event:EventValue). The same applies to the
Boolean return type defined for the figure, which is defined in the OTX Core and is marked accordingly with
the otx: prefix (otx:BooleanTerm). The type IsDiagServiceEvent itself is not prefixed since is a
member of the currently described OTX DiagCom extension.
otx:BooleanTerm
«XSDcomplexType»
IsDiagServiceEvent
«XSDelement»
+ event: event:EventValue
Figure 2 — Example: Usage of extension prefixes

6 OTX DateTime extension
6.1 Introduction
The purpose of the OTX DateTime extension is to retrieve information about the current date and time
provided by the diagnostic application.
6.2 Terms
6.2.1 Overview
The terms in the OTX DateTime extension shall be used to retrieve information about the current system time.
6.2.2 Syntax
Figure 3 shows the syntax of all terms in the OTX DateTime extension.
otx:IntegerTerm otx:StringTerm otx:StringTerm
«XSDcomplexType» «XSDcomplexType» «XSDcomplexType»
GetTimestamp FormatDate FormatDuration
«XSDelement» «XSDelement»
+ timestamp: otx:IntegerTerm + duration: otx:IntegerTerm
+ format: otx:StringTerm [0.1] + format: otx:StringTerm [0.1]

Figure 3 — Data model view: TimeDate terms
6.2.3 Semantics
6.2.3.1 GetTimeStamp
GetTimestamp shall return a timestamp, expressed in milliseconds elapsed since 1970-01-01 00:00:00 UTC.
The semantics of GetTimestamp shall be according to the java.util.Date.getTime() method as
specified by the Java™ 2 Platform Standard Ed. 6.
GetDate is an otx:Integer term. It has no members.
6.2.3.2 FormatDate
The FormatDate term shall transform a timestamp (see GetTimestamp term above) into a date
representation which shall be formatted as follows:
a) In case there is no custom format specified, the returned string shall be formatted according to the rules
given by the ISO 8601 standard [ISO 8601:2004].
b) If a custom format is given (by the element), the string shall be formatted according to the
cusom format rules as specified below.
The custom format pattern can be configured by the OTX author; it controls the text presentation of the date.
A format pattern consists of one or more predefined date and time format specifiers (see Table 3) as well as
user-defined string sequences which have to be escaped by quotes ('). Non-numeric outputs (e.g. the name
of a month) shall be translated automatically to the currently set locale (cf. Clause 12, OTX i18n extension).
10 © ISO 2012 – All rights reserved

Table 3 — Date format pattern specifiers
Specifier(s) Meaning Presentation Example
G AD
Era Text (localized)
yy, yyyy 11, 2011
Year (two digits / four digits) Number
M, MM 9, 09
Month in year (without / with leading zero) Number
MMM, MMMM Jan, January
Month in year (short form / long form) Text (localized)
d, dd 3, 09
Day in month (without / with leading zero) Number
D 304
Day in year Number
F 3
Day of week of month Number
E, EEEE Day of week (short form / long form) Text (localized) Wed, Wednesday
h, hh 7, 07
Hours, 1-12 count (without / with leading zero) Number
H, HH 7, 07
Hours, 0-23 count (without / with leading zero) Number
m, mm 2, 02
Minutes (without / with leading zero) Number
s, ss Seconds (without / with leading zero) Number 4, 04
S, SS, SSS 357, 034, 002
Milliseconds (without / with leading zeros) Number
w, W 34, 3
Week in year / Week in month Number
a AM
AM/PM designator Text (localized)
z, zzzz Time zone (short form / long form) Text (localized) CET, Central European Time
Z +0100
RFC 822 timezone (timeshift to GMT) Text

The format pattern rules are analogous to the rules given for the class java.text.SimpleDateFormat as
specified by the Java™ 2 Platform Standard Ed. 6. The overall semantics of FormatDate shall be according
to the semantics of the method SimpleDateFormat.format(Date date).
EXAMPLE 1 At a given date and time of 2011-03-10 11:23:56 in the Central European Time zone (CET) and with the
current locale set to en-US, a pattern like e.g. "hh 'o''clock' a, zzzz" would produce the following formatted
output: "11 o'clock AM, Central European Time."
If no custom format is given, the ISO 8601 conform date output shall be formatted equivalent to the custom
pattern "yyyy-MM-dd'T'HH:mm:ss'.'SSSZ", where "T" is the time designator and "." is a separator for
the following millisecond portion. This pattern is language independent; the currently set locale does not
influence the output.
EXAMPLE 2 At a given date and time of 2011-03-10 11:23:56 in the Central European Time zone (CET), the following
standard-format output will be produced: "2011-03-10T11:23:56.123+0100".
FormatDate is an otx:StringTerm. Its members have the following semantics:
 : otx:NumericTerm [1]
This element represents a date given as timestamp which shall be interpreted as amount of milliseconds
elapsed since January 1, 1970 00:00:00 UTC.
...