Subject: Re: Washington Issue 7 - Time Local or UTC

From: Matt Holdrege <[email-masked]>
Date: Mon, 15 Nov 1999 22:18:40 -0800

I seem to recall that Q.931 allows either local or UTC depending on network
requirements. Seeing as Q.931 is the closest existing analogy to MEGACO
it's probably a good reference in this case. But I would really like to
hear from the Operators on this one. Theoretically, it shouldn't matter
what time spec MEGACO uses as long as it can map to your billing system
which will use local time. Right?

At 02:26 PM 11/15/99 -0500, Nancy-M Greene wrote:

>The time should be UTC time. Below is an excerpt from X.680, defining what
>that is.
>
>42      Universal time
>42.1    This type shall be referenced by the name:
>         UTCTime
>42.2    The type consists of values representing:
>a)      calendar date; and  b)      time to a precision of one minute or
>one second; and  c)      (optionally) a local time differential from
>coordinated universal time.
>
>42.3    The type is defined, using ASN.1, as follows:
>         UTCTime ::= [UNIVERSAL 23] IMPLICIT VisibleString
>with the values of the "VisibleString" restricted to strings of characters
>which are the juxtaposition of:
>a)      the six digits YYMMDD where YY is the two low-order digits of the
>Christian year, MM is the month (counting January as 01), and DD is the
>day of the month (01 to 31); and b)      either:
>1)      the four digits hhmm where hh is hour (00 to 23) and mm is minutes
>(00 to 59); or  2)      the six digits hhmmss where hh and mm are as in 1)
>above, and ss is seconds (00 to 59); and
>c)      either:
>1)      the character Z; or  2)      one of the characters + or -,
>followed by hhmm, where hh is hour and mm is minutes.
>
>The alternatives in b) above allow varying precisions in the specification
>of the time.
>In alternative c) 1), the time is coordinated universal time. In
>alternative c) 2), the time (t1) specified by a) and b) above is the local
>time; the time differential (t2) specified by c) 2) above enables the
>coordinated universal time to be determined as follows:
>
>         Coordinated universal time is t1 - t2
>EXAMPLE 1 - If local time is 7am on 2 January 1982 and coordinated
>universal time is 12 noon on 2 January 1982, the value of UTCTime is either of:
>-       "8201021200Z"; or  -       "8201020700-0500".
>
>EXAMPLE 2 - If local time is 7am on 2 January 2001 and coordinated
>universal time is 12 noon on 2 January 2001, the value of UTCTime is either of:
>-       "0101021200Z"; or  -       "0101020700-0500".
>
>42.4    The tag shall be as defined in 42.3.
>42.5    The value notation shall be the value notation for the
>"VisibleString" defined in 42.3.
>
>
>Nancy
>--------------------------------------------------------------------------
>Nancy M. Greene
>Internet & Service Provider Networks, Nortel Networks
>T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
>----------  From:   Brian Rosen[SMTP:[email-masked]]  Sent:   Monday,
>November 15, 1999 2:06
>PM  To:     [email-masked]  Subject:
>Washington Issue 7 - Time Local or UTC
>
>A number of issues were raised in the Washington meeting that  were "send
>to the list". This is one of these issues, with the  problem and my
>suggested fix.
>
>Problem
>
>Timestamps don't specify the zone.  Could be local or UTC
>
>Proposed Solution  All times should be reported in UTC
>
>Brian

---

From: Al Varney <[email-masked]>
Date: Tue, 16 Nov 1999 10:01:41 -0600

>which will use local time. Right?

   The Date/Time info in Q.931 is for display/usage by the end user, not
for event time-stamps.  (And I'd suggest GR-303 and V5.2 are better
analogies to MEGACO -- but they, like Q.931, have virtually instantaneous
event notification and thus no need for time-stamps on messages.  It's
the variable delay in message transport that creates a need for message
time-stamps in MEGACO.)

   It seems to me the use of time-stamps in MEGACO is primarily (and
perhaps ONLY) for determining durations between events and/or the sending
of messages.  Thus the actual Date/Time reference point doesn't matter.
Certainly there is no need to synchronize the MG time with MGC time or
other MG times.  What DOES matter is the ability to measure duration in
fractions-of-seconds.

>>The time should be UTC time. Below is an excerpt from X.680, defining what

   Around 30 July 1999, the mailing list suggestion (Chris Ross) was to
follow ISO 8601:1988, using (in text) a format that includes a 4-digit
year.  That may not be real important - X.680 will go from 9912312399 to
0001010000 the end of this year, but this form does have a Y3K problem.

   Last summer's discussion included these comments from me, with little
objection at the time:

   "I support Chris on this, with a minor change. Some documents (relics
    from the telephony world) insist that events such as "Answer" and
    "Disconnect" be recorded in tenths-of-second notation. Some allowance
    is made for "sensor error" (between actual event and ability of system
    to reliably detect the event), but it seems the protocol should at least
    be capable of carrying fractional-second time-stamps, should some
    equipment desire to do generate them. Note that these recordings are
    used to calculate interval/duration measurements -- actual world-time
    need not be tightly synchronized with this clock."

    Also, I liked the ISO 8601 suggestion of a "T" delimiter, thus:

           YYYYMMDDThhmmss[ss] as in 19990730T15525511

    The "T" is both a delimiter and a visual aid in spotting time-stamps.
    Systems with tenths-of-second interval counters but not hundreds-of-second
    could just send a 0 as the last digit. The fractional digits would be
    optional?"

>>-       "8201021200Z"; or  -       "8201020700-0500".

   Even if X.680 is followed, the time-stamp NEEDS a tenths-of-seconds
field, and would probably benefit from hundredths-of-seconds as well.
It doesn't really NEED a year or month field -- assuming events separated
by days are dealt with in the MGC.

-----------
   SUMMARY:  For text-based MEGACO, pick either X.680 (YYMMDDHHMMSS) or the
ISO 8601 form (UTC implied) but ADD 2 fractional seconds to the
representation.
If folks would like the "T" delimiter (so time-stamps stand out visually),
fine.  Don't place any requirements on synchronization of time-stamps between
MGs or between MG and MGCs.

   In binary versions of the protocol, a timestamp in NTP (middle 32 bits)
format is probably useful (and RTP-based MGs will need it anyway for reports).

Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Tue, 16 Nov 1999 08:38:22 -0800

Al Varney writes:
 > analogies to MEGACO

Yeah, that was my thought too.

 > other MG times.  What DOES matter is the ability to measure duration in

I've got a question: Brian and I were talking
about something like this on the way to the
airport. Is the reason for this for sequencing the
arrival of events at the MGC? If so, maybe what we
need here isn't a timestamp at all, per se, but a
incrementing sequence number where the MG MAY put
some sort of locally interesting clock as the
value, but is not required.

If we don't need strict timing, I'd just assume
keeping it both out of the MG and out of the
protocol given the giant rat hole of clock skew,
etc, we'd be introducing.

                Mike