• Version: V1.1.0

  • Version Date: 2014-10-07

  • Prepared by: PUID Working Group

Revision History

Revision

Date (yyyy-mm-dd)

Comments

V1.1.0

2014-10-07

Adopted by the Bluetooth SIG BoD

Contributors

Name

Company

Michael Kirwan

Bluetooth SIG

Satomi Michitsuta

Casio

Sadao Nagashima

Casio

Nobuto Fukushima

Citizen

Daisuke Matsuoh

Citizen

Toshifumi Arai

Citizen

Robin Heydon

CSR plc

Emmanuel Fleury

EM Microelectronic

Reto Galli

EM Microelectronic

Toshio Kimura

Epson

Shunsuke Koyama

Epson

Satoshi Oshiyama

Epson

Robert Hughes

Intel

Ashok Kelur

Mindtree

Krishna Shingala

Mindtree

Dan Sadler

Motorola

Keith Jachim

Motorola

Kanji Kerai

Nokia

Juha Salokannel

Nokia

Frank Berntsen

Nordic Semiconductor

Niclas Granquist

Polar

Brian Redding

Qualcomm

Giriraj Goyal

Samsung

DISCLAIMER AND COPYRIGHT NOTICE

This disclaimer applies to all draft specifications and final specifications adopted by the Bluetooth SIG Board of Directors (both of which are hereinafter referred to herein as a Bluetooth “Specification.” Your use of this Specification in any way is subject to your compliance with all conditions of such use, and your acceptance of all disclaimers and limitations as to such use, contained in this Specification. Any user of this Specification is advised to seek appropriate legal, engineering or other professional advice regarding the use, interpretation or effect of this Specification on any matters discussed in this Specification.

Use of Bluetooth Specifications and any related intellectual property is governed by the Promoters Membership Agreement among the Promoter Members and Bluetooth SIG (the “Promoters Agreement”), certain membership agreements between Bluetooth SIG and its Adopter and Associate Members, including, but not limited to, the Membership Application, the Bluetooth Patent/Copyright License Agreement and the Bluetooth Trademark License Agreement (collectively, the “Membership Agreements”) and the Bluetooth Specification Early Adopters Agreements (1.2 Early Adopters Agreements) among Early Adopter members of the unincorporated Bluetooth SIG and the Promoter Members (the “Early Adopters Agreement”). Certain rights and obligations of the Promoter Members under the Early Adopters Agreements have been assigned to Bluetooth SIG by the Promoter Members.

Use of the Specification by anyone who is not a member of Bluetooth SIG or a party to an Early Adopters Agreement (each such person or party, a “Member”) is prohibited. The use of any portion of a Bluetooth Specification may involve the use of intellectual property rights ("IPR"), including pending or issued patents, or copyrights or other rights. Bluetooth SIG has made no search or investigation for such rights and disclaims any undertaking or duty to do so. The legal rights and obligations of each Member are governed by the applicable Membership Agreements, Early Adopters Agreement or Promoters Agreement. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein.

Any use of the Specification not in compliance with the terms of the applicable Membership Agreements, Early Adopters Agreement or Promoters Agreement is prohibited and any such prohibited use may result in (i) termination of the applicable Membership Agreements or Early Adopters Agreement and (ii) liability claims by Bluetooth SIG or any of its Members for patent, copyright and/or trademark infringement claims permitted by the applicable agreement or by applicable law.

THE SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, SATISFACTORY QUALITY, OR REASONABLE SKILL OR CARE, OR ANY WARRANTY ARISING OUT OF ANY COURSE OF DEALING, USAGE, TRADE PRACTICE, PROPOSAL, SPECIFICATION OR SAMPLE.

Each Member hereby acknowledges that products equipped with the Bluetooth wireless technology ("Bluetooth Products") may be subject to various regulatory controls under the laws and regulations of various governments worldwide. Such laws and regulatory controls may govern, among other things, the combination, operation, use, implementation and distribution of Bluetooth Products. Examples of such laws and regulatory controls include, but are not limited to, airline regulatory controls, telecommunications regulations, technology transfer controls and health and safety regulations. Each Member is solely responsible for the compliance by their Bluetooth Products with any such laws and regulations and for obtaining any and all required authorizations, permits, or licenses for their Bluetooth Products related to such regulations within the applicable jurisdictions. Each Member acknowledges that nothing in the Specification provides any information or assistance in connection with securing such compliance, authorizations or licenses. NOTHING IN THE SPECIFICATION CREATES ANY WARRANTIES, EITHER EXPRESS OR IMPLIED, REGARDING SUCH LAWS OR REGULATIONS.

ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS OR FOR NONCOMPLIANCE WITH LAWS, RELATING TO USE OF THE SPECIFICATION IS EXPRESSLY DISCLAIMED. To the extent not prohibited by law, in no event will Bluetooth SIG or its Members or their affiliates be liable for any damages, including without limitation, lost revenue, profits, data or programs, or business interruption, or for special , indirect, consequential, incidental or punitive damages, however caused and regardless of the theory of liability, arising out of or related to any furnishing, practicing, modifying, use or the performance or implementation of the contents of this Specification, even if Bluetooth SIG or its Members or their affiliates have been advised of the possibility of such damages. BY USE OF THE SPECIFICATION, EACH MEMBER EXPRESSLY WAIVES ANY CLAIM AGAINST BLUETOOTH SIG AND ITS PROMOTER MEMBERS RELATED TO USE OF THE SPECIFICATION.

If this Specification is an intermediate draft, it is for comment only; no products should be designed based on it for purposes other than interoperable prototype testing; and it does not represent any commitment to release or implement any portion of the intermediate draft, which may be withdrawn, modified or replaced at any time, in the adopted Specification.

Bluetooth SIG reserves the right to adopt any changes or alterations to the Specification it deems necessary or appropriate.

Copyright © 2010 - 2014. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. All copyrights in the Bluetooth Specifications themselves are owned by Ericsson AB, Lenovo (Singapore) Pte. Ltd., Intel Corporation, Microsoft Corporation, Motorola Mobility, LLC, Nokia Corporation and Toshiba Corporation. Other third-party brands and names are the property of their respective owners.

Document Terminology

The Bluetooth SIG has adopted Section 13.1 of the IEEE Standards Style Manual, which dictates use of the words “shall”, “should”, “may”, and “can” in the development of documentation, as follows:

The word shall is used to indicate mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted (shall equals is required to).

The use of the word must is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations.

The use of the word will is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact.

The word should is used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain course of action is deprecated but not prohibited (should equals is recommended that).

The word may is used to indicate a course of action permissible within the limits of the standard (may equals is permitted).

The word can is used for statements of possibility and capability, whether material, physical, or causal (can equals is able to).

The term Reserved for Future Use (RFU) is used to indicate Bluetooth SIG assigned values that are reserved by the Bluetooth SIG and are not otherwise available for use by implementations.

1. Introduction

Many Bluetooth devices have the ability to store and show date and time information. This service defines how a Bluetooth device can expose date and time information to other Bluetooth devices. The term “server device” in this specification refers to the device that exposes date and time information by implementing this specification. A device that uses the exposed information is referred to as a “client device”.

1.1. Conformance

If a server claims conformance to this Service, all capabilities indicated as mandatory for this Service shall be supported in the specified manner (process-mandatory). This also applies for all optional and conditional capabilities for which support is indicated. All mandatory capabilities, and optional and conditional capabilities for which support is indicated, are subject to verification as part of the Bluetooth qualification program.

1.2. Service Dependency

This service is not dependent on any other services.

1.3. Bluetooth Specification Release Compatibility

This specification is compatible with Bluetooth Core Specification 4.0 or later [1].

1.4. GATT Sub-Procedure Requirements

Additional GATT Sub-Procedures requirements beyond those required by the GATT are indicated in Table 1.1.

GATT Sub-Procedure

Requirements

Notification

M

Read Characteristic Descriptors

M

Write Characteristic Descriptors

M

Write Characteristic Value

O

Table 1.1. GATT Sub-Procedure Requirements

1.5. Transport Dependencies

There are no transport restrictions imposed by this service specification..

Where the term BR/EDR is used throughout this document, this also includes the use of AMP.

1.6. Error Codes

This service defines the following Attribute Protocol Application Error codes:

Name

Error Code

Description

Data field ignored

0x80

The server ignored one or more fields

1.7. Byte Transmission Order

All characteristics used with this service shall be transmitted with the least significant octet first (i.e., little endian). In the characteristic definitions in the Assigned Numbers [2] the least significant octet is the lowest numbered offset.

2. Service Declaration

The Current Time service shall be a «Primary Service» and the service UUID set to «Current Time Service» as defined in [2].

There shall be only one instance of the Current Time Service in a device.

3. Service Characteristics

The Current Time Service exposes Current Time characteristic. It optionally exposes Local Time Information characteristic and Reference Time Information characteristic. All these characteristics are defined in [2].

Characteristics for Current Time Service
Figure 3.1. Characteristics for Current Time Service

The following characteristics are exposed in an instance of Current Time service.

Characteristic

Ref.

Mandatory / Optional

Current Time

3.1

M

Local Time Information

3.2

O

Reference Time Information

3.3

O

Table 3.1. Service characteristics

In Table 3.2, characteristics that are mandatory or characteristics that are optional that are implemented shall comply with the properties in Table 3.3:

Broadcast

Read

Write without Response

Write

Notify

Indicate

Signed Write

Reliable Write

Writable Auxiliaries

Current Time

X

M

X

O

M

X

X

X

X

Local Time Information

X

M

X

O

X

X

X

X

X

Reference Time Information

X

M

X

X

X

X

X

X

X

Table 3.2. Characteristic properties

Requirements marked with ‘M’ are mandatory, ‘O’ are optional, and ‘X’ are excluded (not permitted).

An example characteristic database is shown in Appendix A.

3.1. Current Time

In this section, the term “local date and time” refers to the internal representation of date and time which is maintained by the server device. During read or notify GATT operations, the fields of the Current Time characteristic are set to values derived from the local date and time. During write GATT operation, the local date and time is optionally set to values derived from the fields of the Current Time characteristic.

3.1.1. Characteristic Behavior – Read

The Current Time characteristic returns the current date and time in the server device when read by a client device using the GATT Read Characteristic Value sub-procedure. The date and time values returned shall be the local date and time of the server device (the time the server device would display to the user, which is normally the correct time for the location adjusted for time zone and DST).

The server device shall set the Exact Time 256 field to the current local date and time. If the server device does not support the 1/256th of seconds, it shall set the Fractions256 field to 0.

If the information about the date or day of week is not available, the server device shall set the values of the fields Year, Month, Day, and/or Day of Week to 'unknown' [2].

3.1.2. Characteristic Behavior – Notification

This characteristic can be configured for notification using the GATT Write Characteristic Descriptors sub-procedure on the Client Characteristic Configuration descriptor. When configured for notification, this characteristic can be notified while in a connection.

A server device shall notify this characteristic to the client device depending on the value of Client Characteristic Configuration descriptor when the time of the server device is adjusted. The events that can cause the local time in the server device to change are user interaction (setting time via UI), time zone change, DST offset change, or reference time change. These events are not exclusive.

If the time of the server device is changed because of reference time update, then no notifications shall be sent to the client device within the 15 minutes from the last notification, unless one or both of the two statements below are true:

  1. The new time information differs by more than 1 minute from the server device time previous to the update.

  2. The update was caused by the client device (interacting with another service).

Notifications caused by other events, like the change of time zone or DST offset and adjustment by the user, shall be conveyed to the client device immediately.

The server device shall set the Adjust Reason field in the Current Time to reflect the reason for the last adjustment of the local time on the server device.

After initialization or in any other case when the reason for the last change update of time in the server device is not known, all the bits in the Adjust Reason field shall be set to zero. When time is updated in the server device, and the reason is known, the bits in the Adjust Reason field shall be set according to section 3.1.2.1, 3.1.2.2, 3.1.2.3, and 3.1.2.4 (The format of the Adjust Reason field is defined in [2]).

3.1.2.1. Manual Time Update

If the time information on the server device was set / changed manually, the “Manual Time Update” bit shall be set.

Note: If the time zone or DST offset were changed manually, this bit shall also be set.

3.1.2.2. External Reference Time Update

If the server device received time information from an external time reference source, the External Reference Time Update bit shall be set.

3.1.2.3. Change of Time Zone

If the time information on the server device was set / adjusted because of change of time zone, the “Change of Time Zone” bit shall be set.

Note: Following 3.1.2.1, if the time zone was changed manually the “Manual Time Update” bit will also be set.

3.1.2.4. Change of DST Offset

If the time information on the server device was set / adjusted because of change of DST offset, the “Change of DST offset” bit shall be set.

Note: Following 3.1.2.1, if the DST offset was changed manually, the “Manual Time Update” bit will also be set.

3.1.3. Characteristic Behavior – Write

When the Current Time characteristic is written using the GATT Write Characteristic Value sub-procedure, the server device may adjust the local date and time of the server device to a value derived from the value in the Current Time characteristic. The server device may choose to ignore fields in the values written to its Current Time characteristic. If one or more fields are ignored, the server device shall return an error code as defined in Section 1.6.

3.1.4. Characteristic Descriptors

3.1.4.1. Client Characteristic Descriptor

The Client Characteristic Configuration descriptor shall be included in this characteristic.

This descriptor shall be readable and writable.

This descriptor can be read using the GATT Read Characteristic Descriptors sub-procedure.

This descriptor can be written using the GATT Write Characteristic Descriptors sub-procedure.

3.2. Local Time Information

In this section, the terms “current time zone” and “current DST offset” refer to the internal representation of information about local time which is maintained by the server device. During read GATT operation, the fields of the Local Time Information characteristic are set to values derived from the current time zone and current DST offset. During write GATT operation, the current time zone and current DST offset are optionally set to values derived from the fields of the Local Time Information characteristic.

3.2.1. Characteristic Behavior – Read

The Local Time Information characteristic returns the local time information that includes time zone and DST offset when read using the GATT Read Characteristic Value sub-procedure.

If the Local Time Information characteristic exists, the server device shall set the Time zone field of the Local Time Information to the offset of the local standard time compared to UTC and the DST offset field of Local Time Information to the current DST offset. If time zone and DST offset information are currently unavailable, the server device may set the fields to the values defined as 'time zone unknown' [2] or 'DST offset unknown' [2].

3.2.2. Characteristic Behavior – Write

When the Local Time Information characteristic is written using the GATT Write Characteristic Value sub-procedure, the server may adjust the current time zone and/or the current DST offset to the values in the Local Time Information characteristic. The server device may choose to ignore fields in the values written to its Local Time Information characteristic. If one or more fields are ignored, the server device shall return an error code as defined in Section 1.6.

3.2.3. Characteristic Descriptors

No characteristic descriptors are required beyond those defined in the characteristic specification.

3.3. Reference Time Information

The Reference Time Information characteristic returns the information about the reference time source when read using the GATT Read Characteristic Value sub-procedure.

If Reference Time Information exists, the server device shall set the Time Source field of the Reference Time Information characteristic to the value that represents the source of its current time information. It is assumed that the server device will use its best source available (at a given time), but it is outside the scope of this service to specify how the server device uses its reference time sources.

The server device shall set the Days Since Update and Hours Since Update fields of Reference Time Information characteristic to the time span that passed since the Time was updated successfully from the source specified in Time Source field. If the last update was more than 254 days and 23 hours ago, both values shall be set to 255.

The server device shall set the Accuracy field of the Reference Time Information characteristic to the estimated accuracy (drift) of its time information compared to the original time source (e.g., a server device with a real-time clock that is rated to drift a maximum 750 ms a day, and that acquired the last time update 48 hours ago might have drifted 1.5s, thus it will set the Accuracy field to 12 (12/8=1.5 s). If a server device does not know the accuracy of its time information, it shall set the Accuracy field to 255 (Accuracy unknown).

A server device that does not support the Fractions256 field in Current Time characteristic shall set the Time Accuracy field to the larger value of the actual accuracy and 1 second.

3.3.1. Characteristic Descriptors

No characteristic descriptors are required beyond those defined in the characteristic specification.

4. SDP Interoperability

If this service is exposed over BR/EDR then it shall have the following SDP record.

Item

Definition

Type

Value

Status

Service Class ID List

M

Service Class #0

UUID

«Current Time Service»

M

Protocol Descriptor List

M

Protocol #0

UUID

L2CAP

M

Parameter #0 for Protocol #0

PSM

Uint16

PSM = ATT

M

Protocol #1

UUID

ATT

M

Parameter #0 for Protocol #1

GATT Start Handle

Uint16

First handle of this service in the GATT database

M

Parameter #1 for Protocol #1

GATT End Handle

Uint16

Last handle of this service in the GATT database

M

BrowseGroupList

PublicBrowseRoot*

M

Table 4.1. SDP Record

* PublicBrowseRoot shall be present; however, other browse UUIDs may also be included in the list.

5. Acronyms and Abbreviations

Acronyms and Abbreviations

Meaning

AMP

Alternate MAC PHY

BR/EDR

Basic Rate / Enhanced Data Rate

DST

Daylight Saving Time

LE

Low Energy

UTC

Coordinated Universal Time

UUID

Universally Unique Identifier

Table 5.1. Acronyms and Abbreviations

6. References

[1] Bluetooth Core Specification v4.0 or later

[2] Characteristic and Descriptor descriptions are accessible via the Bluetooth SIG Assigned Numbers

Appendix A. Example Attribute Database

An example attribute database for Current Time Service is shown as follows:

UUID [2]

Permissions

Mandatory/ Optional

Value (Default)

<<Primary Service>>

Read

M

<<Current Time Service>>

<<Characteristic>>

Read

M

Properties = 0x12 (read, notify),

Handle = Handle of Current Time,

UUID = <<Current Time>>

<<Current Time>>

Read, Notify

M

ref [2]

<<Client Characteristic Configuration>>

Read, Write

M

0x0000

<<Characteristic>>

Read

O

Properties = 0x02 (read),

Handle = Handle of Local Time Information,

UUID = <<Local Time Information>>

<<Local Time Information>>

Read

O

ref [2]

<<Characteristic>>

Read

O

Properties = 0x02 (read),

Handle = Handle of Reference Time Information,

UUID = <<Reference Time Information>>

<<Reference Time Information>>

Read

O

ref [2]