Loading ...
Sorry, an error occurred while loading the content.

Re: [eiffel_software] partial date/times in Eiffel and why there are two date/time libraries

Expand Messages
  • Eric Bezault
    ... ISE EiffelTime library has been there for ages, and as far as I know there is no real problem in it that is addressed by the Gobo Eiffel Time library. The
    Message 1 of 7 , May 2, 2005
    • 0 Attachment
      Thomas Beale wrote:
      > In openEHR (openEHR.org) we use partial date/times, i.e. date/times with
      > unknown parts, e.g. following the pattern YYYY-MM-??. In the literal
      > format of ISO 8601 a typical partial date would be 1984-04. To support
      > such things we created our own classes in the openEHR data types
      > information model. However, we now have a need to have partial versions
      > of the standard library DATE, TIME, DATE_TIME classes. I don't mind
      > implementing them - we can fairly quickly implement PARTIAL_DATE,
      > PARTIAL_TIME and PARTIAL_DATE_TIME. The questions I have is about
      > re-use: if others might be interested in using such classes, which
      > library could they be added to? There are two date/time libraries in
      > common use as far as I know - the Gobo and the ISE libraries. I
      > currently use the ISE ones, but I don't know really why there are two.
      > Which should I be using? What's wrong with the other one? Why can't they
      > be merged? What is the future of these libraries?

      ISE EiffelTime library has been there for ages, and as far
      as I know there is no real problem in it that is addressed
      by the Gobo Eiffel Time library. The raison d'etre of the
      Gobo library (and likewise for Gobo Data Structure vs. ISE
      EiffelBase, etc.) is that the code provided in the Gobo
      package compiles and works with all supported Eiffel
      compilers, not just ISE Eiffel compiler.

      I don't know if this is still the case, but one difference
      in the design between EiffelTime and Gobo Time was that in
      EiffelTime we have something like that:

      create my_date_time.make_now

      whereas in Gobo we have clock objects which can return the
      current date and time. This can be useful for simulation
      programs where you want the time to run twice faster than
      the wall clock: just polymorphically attach to your clock
      entity an instance of a descendant of the CLOCK class
      which does the trick. You can also have CLOCKs for different
      time zones, etc.

      As for 1984-04, should it be a PARTIAL_DATE or a MONTH?
      PARTIAL_* sounds vague to me. Is DATE a PARTIAL_DATE_TIME?

      --
      Eric Bezault
      mailto:ericb@...
      http://www.gobosoft.com
    • Thomas Beale
      ... A question to the community at large: isn t it time we had one library, not many for things such as time? Clearly it wants to work on all compilers which
      Message 2 of 7 , May 2, 2005
      • 0 Attachment
        Eric Bezault wrote:

        >Thomas Beale wrote:
        >
        >
        >>Which should I be using? What's wrong with the other one? Why can't they
        >>be merged? What is the future of these libraries?
        >>
        >>
        >
        >ISE EiffelTime library has been there for ages, and as far
        >as I know there is no real problem in it that is addressed
        >by the Gobo Eiffel Time library. The raison d'etre of the
        >Gobo library (and likewise for Gobo Data Structure vs. ISE
        >EiffelBase, etc.) is that the code provided in the Gobo
        >package compiles and works with all supported Eiffel
        >compilers, not just ISE Eiffel compiler.
        >
        >
        A question to the community at large: isn't it time we had one library,
        not many for things such as time? Clearly it wants to work on all
        compilers which respect the language definition. Presumably this still
        means SmartEiffel and Object Tools' compilers?

        I see it as a real concern now that we still do not have a community
        wide set of integrated libraries, rather than various midly different
        flavours whose currency and comparitive virtues are not clear. This is
        of course not a criticism of the gobo libraries nor even the ISE
        libraries - maybe it is a criticism of our whole community....but I
        really do think that something needs to be done about it ASAP. I want to
        see the day soon when I get a new version of any compiler, and there is
        just one BASE, one TIME, one NET, etc etc. Then we can achieve a few things:
        a) proper integration of all libraries
        b) the community can contribute bugfixes and diagnoses to one code base
        c) more reliable documentation and educational materials (e..g web docs)
        can be developed

        >I don't know if this is still the case, but one difference
        >in the design between EiffelTime and Gobo Time was that in
        >EiffelTime we have something like that:
        >
        > create my_date_time.make_now
        >
        >whereas in Gobo we have clock objects which can return the
        >current date and time. This can be useful for simulation
        >programs where you want the time to run twice faster than
        >the wall clock: just polymorphically attach to your clock
        >entity an instance of a descendant of the CLOCK class
        >which does the trick. You can also have CLOCKs for different
        >time zones, etc.
        >
        >
        Sounds like a good design enhancement; as long as it allows the library
        to be used in 'normal' mode for 'normal' things...

        >As for 1984-04, should it be a PARTIAL_DATE or a MONTH?
        >PARTIAL_* sounds vague to me. Is DATE a PARTIAL_DATE_TIME?
        >
        >
        well, that string is an ISO9601 string; I don't happen to agree with the
        ISO8601 approach to rendering partial dates and times, because it
        becomes increasingly less clear if the thing you have is a date or
        something else (e.g. "1984" is a date with no month or day, but only a
        human would easily guess that).

        But don't worry about the string format too much; the idea of partial
        date times is Date/Times with pieces "missing from the right hand end".
        Well, that's one way to model it anyway - see the openEHR models for an
        example -
        http://www.openehr.org/repositories/spec-dev/latest/publishing/architecture/rm/data_types_im.pdf,
        date/time section.

        Partial dates and date/times occur all the time in clinical medicine.

        - thomas beale



        --
        ___________________________________________________________________________________
        Research Fellow, University College London (http://www.chime.ucl.ac.uk)
        Chair Architectural Review Board, openEHR (http://www.openEHR.org)
        CTO Ocean Informatics (http://www.OceanInformatics.biz)
      • Colin Paul Adams
        ... Thomas well, that string is an ISO9601 string; I don t happen to Thomas agree with the ISO8601 approach to rendering partial dates Thomas and times,
        Message 3 of 7 , May 2, 2005
        • 0 Attachment
          >>>>> "Thomas" == Thomas Beale <thomas@...> writes:

          >> As for 1984-04, should it be a PARTIAL_DATE or a MONTH?
          >> PARTIAL_* sounds vague to me. Is DATE a PARTIAL_DATE_TIME?
          >>
          >>
          Thomas> well, that string is an ISO9601 string; I don't happen to
          Thomas> agree with the ISO8601 approach to rendering partial dates
          Thomas> and times, because it becomes increasingly less clear if
          Thomas> the thing you have is a date or something else
          Thomas> (e.g. "1984" is a date with no month or day, but only a
          Thomas> human would easily guess that).

          ISO 8601 calls these truncated dates, and says they can only be used
          by agreement - so the program knows what to expect, and does not have
          to guess.
          --
          Colin Paul Adams
          Preston Lancashire
        • Stan Hendryx
          ... Basing a (reusable?) library class for dates on a particular data storage structure or string format seems backwards. Why not have a (possibly deferred,
          Message 4 of 7 , May 2, 2005
          • 0 Attachment
            >>As for 1984-04, should it be a PARTIAL_DATE or a MONTH?
            >>PARTIAL_* sounds vague to me. Is DATE a PARTIAL_DATE_TIME?
            >>
            >>
            >well, that string is an ISO9601 string;



            Basing a (reusable?) library class for dates on a particular data storage
            structure or string format seems backwards. Why not have a (possibly
            deferred, possibly generic) class whose objects each represents some period
            of time as reckoned by a specified calendar in some time zone, and let
            different implementations provide different string formats and storage
            characteristics? Thus, 1984 [Gregorian calendar, GMT-7] represents a
            particular one-year time period. 4/84 [Gregorian] represents a particular
            one month period, viz. April, 1984. 4/15/1984 is a one day period, 4/15/1984
            18:00:00 GMT-7] is a particular one-second time period, etc. All application
            logic involving dates and times could use the deferred features, independent
            of any implementation. The implementation only comes into play when date I/O
            is involved. Different calendars could be provided, including Gregorian,
            Julian, Jewish, Chinese, corporate fiscal calendars, and others, with
            mappings between them, or to the common Gregorian system.



            Stan Hendryx



            _____

            From: eiffel_software@yahoogroups.com
            [mailto:eiffel_software@yahoogroups.com] On Behalf Of Thomas Beale
            Sent: Monday, May 02, 2005 10:22 AM
            To: eiffel_software@yahoogroups.com
            Subject: Re: [eiffel_software] partial date/times in Eiffel and why there
            are two date/time libraries



            Eric Bezault wrote:

            >Thomas Beale wrote:
            >
            >
            >>Which should I be using? What's wrong with the other one? Why can't they
            >>be merged? What is the future of these libraries?
            >>
            >>
            >
            >ISE EiffelTime library has been there for ages, and as far
            >as I know there is no real problem in it that is addressed
            >by the Gobo Eiffel Time library. The raison d'etre of the
            >Gobo library (and likewise for Gobo Data Structure vs. ISE
            >EiffelBase, etc.) is that the code provided in the Gobo
            >package compiles and works with all supported Eiffel
            >compilers, not just ISE Eiffel compiler.
            >
            >
            A question to the community at large: isn't it time we had one library,
            not many for things such as time? Clearly it wants to work on all
            compilers which respect the language definition. Presumably this still
            means SmartEiffel and Object Tools' compilers?

            I see it as a real concern now that we still do not have a community
            wide set of integrated libraries, rather than various midly different
            flavours whose currency and comparitive virtues are not clear. This is
            of course not a criticism of the gobo libraries nor even the ISE
            libraries - maybe it is a criticism of our whole community....but I
            really do think that something needs to be done about it ASAP. I want to
            see the day soon when I get a new version of any compiler, and there is
            just one BASE, one TIME, one NET, etc etc. Then we can achieve a few things:
            a) proper integration of all libraries
            b) the community can contribute bugfixes and diagnoses to one code base
            c) more reliable documentation and educational materials (e..g web docs)
            can be developed

            >I don't know if this is still the case, but one difference
            >in the design between EiffelTime and Gobo Time was that in
            >EiffelTime we have something like that:
            >
            > create my_date_time.make_now
            >
            >whereas in Gobo we have clock objects which can return the
            >current date and time. This can be useful for simulation
            >programs where you want the time to run twice faster than
            >the wall clock: just polymorphically attach to your clock
            >entity an instance of a descendant of the CLOCK class
            >which does the trick. You can also have CLOCKs for different
            >time zones, etc.
            >
            >
            Sounds like a good design enhancement; as long as it allows the library
            to be used in 'normal' mode for 'normal' things...

            >As for 1984-04, should it be a PARTIAL_DATE or a MONTH?
            >PARTIAL_* sounds vague to me. Is DATE a PARTIAL_DATE_TIME?
            >
            >
            well, that string is an ISO9601 string; I don't happen to agree with the
            ISO8601 approach to rendering partial dates and times, because it
            becomes increasingly less clear if the thing you have is a date or
            something else (e.g. "1984" is a date with no month or day, but only a
            human would easily guess that).

            But don't worry about the string format too much; the idea of partial
            date times is Date/Times with pieces "missing from the right hand end".
            Well, that's one way to model it anyway - see the openEHR models for an
            example -
            http://www.openehr.org/repositories/spec-dev/latest/publishing/architecture/
            rm/data_types_im.pdf,
            date/time section.

            Partial dates and date/times occur all the time in clinical medicine.

            - thomas beale



            --
            ____________________________________________________________________________
            _______
            Research Fellow, University College London (http://www.chime.ucl.ac.uk)
            Chair Architectural Review Board, openEHR (http://www.openEHR.org)
            CTO Ocean Informatics (http://www.OceanInformatics.biz)




            _____

            Yahoo! Groups Links

            * To visit your group on the web, go to:
            http://groups.yahoo.com/group/eiffel_software/

            * To unsubscribe from this group, send an email to:
            eiffel_software-unsubscribe@yahoogroups.com
            <mailto:eiffel_software-unsubscribe@yahoogroups.com?subject=Unsubscribe>

            * Your use of Yahoo! Groups is subject to the Yahoo!
            <http://docs.yahoo.com/info/terms/> Terms of Service.



            [Non-text portions of this message have been removed]
          • Karsten Heusser
            ... What a wonderful (Eiffel) world this would be. Karsten Heusser
            Message 5 of 7 , May 2, 2005
            • 0 Attachment
              > Thomas Beale wrote:
              > I want to see the day soon
              > when I get a new version of any compiler,
              > and there is just one BASE, one TIME, one NET, etc etc.

              What a wonderful (Eiffel) world this would be.

              Karsten Heusser
            Your message has been successfully submitted and would be delivered to recipients shortly.