**IEEE P1451.3 Proposal**

+-----------------+----------------------------------------------------+
| Proposal Title: | Time-of-Day change                                 |
+-----------------+----------------------------------------------------+
| Proposal        | 03-009                                             |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Revision        | B                                                  |
| Number:         |                                                    |
+-----------------+----------------------------------------------------+
| Date:           | 37671.38                                           |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Name:           | Lee Eccles                                         |
+-----------------+----------------------------------------------------+
| Company:        | Boeing                                             |
+-----------------+----------------------------------------------------+
| Phone Number:   | 206-655-2824                                       |
+-----------------+----------------------------------------------------+
| Fax Number:     | 206-655-7724                                       |
+-----------------+----------------------------------------------------+
| Email Address:  | [lee.h.                                            |
|                 | eccles@boeing.com](mailto:Lee.h.eccles@boeing.com) |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+
| Proposal        | Initial Draft                                      |
| Status:         |                                                    |
|                 | [X]{.underline} Revised Draft                      |
|                 |                                                    |
|                 | [X]{.underline} Ready for Vote                     |
+-----------------+----------------------------------------------------+
| Impacts:        | \_\_                                               |
|                 |                                                    |
|                 | \_\_                                               |
+-----------------+----------------------------------------------------+
| Action:         | \_[X]{.underline}\_ Approved                       |
|                 |                                                    |
|                 | \_ \_ Approved with changes                        |
|                 |                                                    |
|                 | \_ \_ Rejected                                     |
|                 |                                                    |
|                 | \_ \_ Returned for revision                        |
+-----------------+----------------------------------------------------+
|                 |                                                    |
+-----------------+----------------------------------------------------+

Background:

The following was received from Bruce Hamilton of Agilent.

We\'ve discovered an ambiguity in the 1588 TimeRepresentation. I\'m
attaching our official comment on the subject (approved by the IEEE-1588
interpretations sub-committee and sent to the IEEE).

This also affects 1451.1. I\'m not sure what Jay is doing about it.

-Bruce

(submitted 15 Jan 2003)

QUESTION:

On the machines I am targeting, the native Integer32 does not have
unique representations for positive and negative zero. This implies that
the struct TimeRepresentation for a positive whole number of seconds
(nanoseconds == 0) is identical to the TimeRepresentation for the
negative same whole number of seconds (nanoseconds == -0). This appears
to be a flaw in the design. Am I missing something here?

Reference clause 5.2.2.

RESPONSE:

You are correct. There is a flaw in the design that results in an
ambiguous interpretation of the struct TimeRepresentation for all
negative time intervals or timestamps, the latter being unlikely in
practice since it implies the epoch is in the future. It is also
impossible to express negative time intervals or timestamps for which
the nanoseconds portion is zero. Please note that by clause 5
implementers may use any internal representation provided it does not
change the semantics of any network visible operation of the protocol.
Representations specified in the standard must be used in any
on-the-wire message defined in the standard.

Given the zero flaw, there is no possible interpretation that can
resolve the issue. This will need to be corrected in the next version of
the standard. The recommendation is to implement as though clause 5.2.2
read:

IDL: struct TimeRepresentation

{

UInteger32 seconds;

UInteger32 nanoseconds;

};

where the nanoseconds member is defined such that the most significant
bit represents the sign bit, 1 indicating a negative number, and the
least significant 31 bits represent the nanoseconds portion of the time
being represented. TimeRepresentation thus defines a sign magnitude
representation for time stamps and time intervals.

The range of the absolute value of the least significant 31 bits of the
nanoseconds portion of the representation shall be restricted to:

0\<= \| least significant 31 bits of nanoseconds\|\< 10^9^

The sign of the nanoseconds member shall be interpreted as the sign of
the entire representation.

For example:

+2.0 seconds is represented by seconds = 0X00000002 and nanoseconds =
0X00000000

-2.0 seconds is represented by seconds = 0X00000002 and nanoseconds =
0X80000000

+2.000000001 seconds is represented by seconds = 0X00000002 and
nanoseconds = 0X00000001

-2.000000001 seconds is represented by seconds = 0X00000002 and
nanoseconds = 0X80000001

Note: This change will require the corresponding changes of the type of
the nanoseconds member from Integer32 to UInteger32 in numerous places
in other clauses of the standard.

**Proposal:**

## 4.14 Time-of-day

Symbol: ToD

Size: 8 octets

The format of the ToD structure is the same as defined in IEEE Std
P1588-2002. Conversion of this format into other possible formats is
described in IEEE Std P1588-2002 Annex B. This structure consists of two
numeric fields described in Table 3.

Note: This format is corrected for the flaw in negative time
representation discovered in IEEE Std 1588-2002.

Table 3---Time-of-day data type structure

  ----------- -------------------------------------------------- -------- ----------
  **Field**   **Description**                                    **Data   **Number
                                                                 Type**   of
                                                                          octets**

  1           **Seconds---**This is an unsigned thirty-two bit   U32C     4
              number that represent the number of seconds from 0          
              hours on 1 January 1970.                                    

  2           **Sign, Nanoseconds---**This is an unsigned        U32C     4
              thirty-two-bit integer that is comprised of two             
              smaller fields. The most significant bit will be            
              interpreted as the sign bit of the entire ToD               
              value. The least significant 31 bits represents             
              the number of nanoseconds to be added to the value          
              identified by the **Seconds** field before the              
              sign is applied. The value specified in the                 
              **Nanoseconds** field is constrained to the domain          
              0 to 999 999 999, inclusive.                                
  ----------- -------------------------------------------------- -------- ----------