Time Service Avatar
  1. OMG Specification

Time Service — All Issues

  • Acronym: TIME
  • Issues Count: 6
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
TIME-6 Elapsed Time since 10/15/1582 TIME 1.0b1 open
TIME-5 Description of the IN parameter tdf is missing (Time Service) TIME 1.0b1 TIME 1.0 Resolved closed
TIME-4 CosTime::TIO::spans and CotTime::TIO::overlaps issue TIME 1.0b1 TIME 1.0 Resolved closed
TIME-3 OMG TimeService spec error TIME 1.0b1 TIME 1.0 Resolved closed
TIME-2 Obsolete reference to readout operation? TIME 1.0 open
TIME-1 Clock Interface TIME 1.0 open

Issues Descriptions

Elapsed Time since 10/15/1582

  • Key: TIME-6
  • Legacy Issue Number: 1985
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Questions: Is there a formula to determine the amount of elapsed time
    >since 10/15/1582 as specified in the TimeService Specification?
    >
    >After finding that September of 1752 only has 19 days and
    >a few different interpretations of leap year rules, I believe
    >there is some ambiguity as to what should be placed in a
    >TimeBase::Utc time value to represent a specific date/time.
    >
  • Reported: TIME 1.0b1 — Tue, 22 Sep 1998 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:50 GMT

Description of the IN parameter tdf is missing (Time Service)

  • Key: TIME-5
  • Legacy Issue Number: 1717
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For the interface
    UTO CosTime::TimeService::new_universal_time(
    in TimeBase::TimeT time,
    in TimeBase::InaccuracyT inaccuracy,
    in TimeBase::TdfT tdf
    );
    the description of the IN parameter tdf is missing.
  • Reported: TIME 1.0b1 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — TIME 1.0
  • Disposition Summary:

    :TimeService::new_universal_time(
  • Updated: Wed, 11 Mar 2015 04:24 GMT

CosTime::TIO::spans and CotTime::TIO::overlaps issue

  • Key: TIME-4
  • Legacy Issue Number: 1713
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: n Appendix B, p14-21 the return type of the interfaces
    CosTime::TIO::spans
    and
    CosTime::TIO::overlaps
    is declared as boolean. This is in contradiction to p 14-10,11 of the
    same document that states a return type of OverlapType.

    The correct return type is OverlapType.
  • Reported: TIME 1.0b1 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — TIME 1.0
  • Disposition Summary:

    :TIO::spans
  • Updated: Wed, 11 Mar 2015 04:24 GMT

OMG TimeService spec error

  • Key: TIME-3
  • Legacy Issue Number: 4979
  • Status: closed  
  • Source: Fujitsu ( Stephen McConnell [X] (Inactive))
  • Summary:

    Just came accoss an issue with the publichsed CosTime IDL.
    The specification for the TIO interface contains a return
    value of OverlapType for a couple of its operations. However,
    the published IDL for CosTime returns a boolean.

    interface TIO

    { OverlapType spans( in UTO time, out TIO overlap); OverlapType overlaps( in TIO interval, out TIO overlap); UTO time (); }

    ;

    IDL defintion:

    interface TIO

    { boolean spans( in UTO time, out TIO overlap); boolean overlaps( in TIO interval, out TIO overlap); UTO time (); }

    ;
  • Reported: TIME 1.0b1 — Fri, 8 Mar 2002 05:00 GMT
  • Disposition: Resolved — TIME 1.0
  • Disposition Summary:

    purely editorial, issue closed
  • Updated: Wed, 11 Mar 2015 04:16 GMT

Obsolete reference to readout operation?

  • Key: TIME-2
  • Legacy Issue Number: 5625
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 2.8.1.2 of the Enhanced Time specification mentions the readout
    operation. Should that be a Clock::current_time attribute instead?
  • Reported: TIME 1.0 — Sun, 1 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clock Interface

  • Key: TIME-1
  • Legacy Issue Number: 4587
  • Status: open  
  • Source: comcast.net ( Dock Allen)
  • Summary:

    The enhanced views of time added an interface for user-defined clocks,
    including requesting synchronized time. However, there is no way to
    tell the ORB what clock to use for the build in CORBA time-related
    functions (timeouts, etc). At a minimum, it would be good to be able to
    get a synchronized ORB clock. Can we move these interfaces into CORE
    for RT CORBA?
  • Reported: TIME 1.0 — Wed, 3 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT