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

RE: [ISO8601] Why three values of dates.

Expand Messages
  • Tex Texin
    It could be all sorts of things. Why have just 2 codes then? What about unknown but approximately in the present? If that s what you want, then why not just
    Message 1 of 19 , Apr 13, 2006
    • 0 Attachment
      It could be all sorts of things. Why have just 2 codes then?
      What about unknown but approximately in the present?
       
      If that's what you want, then why not just stipulate you use 8601 for actual dates and other strings (e.g. "past, future, unknown, etc.) for non-dates and it can be your own format for whatever applications you have. It doesn;t need to be part of iso 8601.
       
      tex


      From: ISO8601@yahoogroups.com [mailto:ISO8601@yahoogroups.com] On Behalf Of hjwoudenberg@...
      Sent: Thursday, April 13, 2006 8:31 PM
      To: ISO8601@yahoogroups.com
      Subject: Re: [ISO8601] Why three values of dates.

      In a message dated 4/13/2006 8:40:33 P.M. Central Daylight Time, tex@... writes:
      in the context of 8601, it would be good to have a uniform way to indicate the value is not a date. Otherwise it is difficult to interchange.
      However, what if it is past or future.
      With bills of mature this is important.
       
      hjw
       
    • hjwoudenberg@aol.com
      In a message dated 4/13/2006 10:50:19 P.M. Central Daylight Time, tex@yahoo-inc.com writes: It doesn;t need to be part of iso 8601. tex Than who? hjw
      Message 2 of 19 , Apr 13, 2006
      • 0 Attachment
        In a message dated 4/13/2006 10:50:19 P.M. Central Daylight Time, tex@... writes:
        It doesn;t need to be part of iso 8601.
         
        tex
        Than who?
        hjw
      • piebaldconsult
        ... The partners in interchange.
        Message 3 of 19 , Apr 14, 2006
        • 0 Attachment
          --- In ISO8601@yahoogroups.com, hjwoudenberg@... wrote:
          >
          >
          > In a message dated 4/13/2006 10:50:19 P.M. Central Daylight Time,
          > tex@... writes:
          >
          > It doesn;t need to be part of iso 8601.
          >
          > tex
          >
          >
          >
          > Than who?
          > hjw
          >

          The partners in interchange.
        • piebaldconsult
          ... indicate ... How is that important? Because you say it s important? If the field on a paper form is left blank or marked N/A or some such it s clear what
          Message 4 of 19 , Apr 14, 2006
          • 0 Attachment
            > in the context of 8601, it would be good to have a uniform way to
            indicate
            > the value is not a date. Otherwise it is difficult to interchange.
            > However, what if it is past or future.
            > With bills of mature this is important.

            How is that important? Because you say it's important? If the field
            on a paper form is left blank or marked N/A or some such it's clear
            what the meaning is.

            I expect this would only be a concern when sending an electronic
            invoice and such, perhaps in XML. In which case I argue that the rule
            could be something like (if agreed to by the partners in interchange):

            "If the date is known, it must be formatted as YYYY-MM-DD, else enter
            Unknown."

            <Invoice>
            <Number>123</Number>
            <SentDate>2006-04-14</SentDate>
            <DueDate>2006-05-14</DueDate>
            <PaidDate>Unknown</PaidDate>
            ...
            </Invoice>

            Each pair of interchange partners must clearly define what they are
            interchanging.

            ISO 8601 is a standard for interchanging _known_ temporal information.

            Remember, that ISO 8601 doesn't even apply a meaning to _real_
            temporal data.
          • hjwoudenberg@aol.com
            In a message dated 4/14/2006 8:29:23 A.M. Central Daylight Time, PIEBALDconsult@aol.com writes: How is that important? Because you say it s important? If the
            Message 5 of 19 , Apr 14, 2006
            • 0 Attachment
              In a message dated 4/14/2006 8:29:23 A.M. Central Daylight Time, PIEBALDconsult@... writes:
              How is that important? Because you say it's important? If the field
              on a paper form is left blank or marked N/A or some such it's clear
              what the meaning is.

              With a bill of material you have two effective dates:
               Part       Effective-from Effective-to
               A           0000-00-00    9999-99-99
              B            0000-00-00    2006-01-01
              C            2006-01-01    9999-01-01
               
              If the effective dates are indexes to the bill-of-materials, than the retrieval for parts in 2006 will give part C, not part B.
               
              maybe you prefer searching through all the parts and testing each from and to date.
               
              Other and I don't.  I don;t think you will find any significant vendor who does not use this method.
               
              hjw
            • piebaldconsult
              ... the ... from and ... vendor who ... Looks like a process-specific usage. Another process may want other values. You and your partners in interchange can
              Message 6 of 19 , Apr 14, 2006
              • 0 Attachment
                > If the effective dates are indexes to the bill-of-materials, than
                the
                > retrieval for parts in 2006 will give part C, not part B.
                >
                > maybe you prefer searching through all the parts and testing each
                from and
                > to date.
                >
                > Other and I don't. I don;t think you will find any significant
                vendor who
                > does not use this method.

                Looks like a process-specific usage. Another process may want other
                values. You and your partners in interchange can agree to do it this
                way. I wouldn't, I'd want to receive empty strings, then internally
                I'd replace them with the appropriate values.

                I also submit that those appropriate values may change, as with year
                10000 (I know, I know, I'll be dead).

                One of my processes needs to sort by a date that may be null, I test
                for null and use:

                System.Data.SqlTypes.SqlDateTime.MinValue
                or
                System.Data.SqlTypes.SqlDateTime.MaxValue

                as appropriate (based on context). That way I'm not tied to a hard-
                coded magic value. (These are .net values.)

                Also, you aren't going to get either of those values into any
                database I know of as a date so why bother? Transmit an empty string
                and put it into the database as a null, but if comparisons are
                needed, replace it as appropriate.
              • Tex Texin
                However, you do not need to define NAD for this. Effectively you are using dates so far in the past or future that they cannot possibly conflict with or be
                Message 7 of 19 , Apr 14, 2006
                • 0 Attachment
                  However, you do not need to define NAD for this.
                  Effectively you are using dates so far in the past or future that they cannot possibly conflict with or be confused with actual dates used by your application.
                   
                  On the other hand, if the application were astronomy or world history those values would be problematic.
                   
                  So on the one hand you could argue that NAD would define a value that all applications agree is not a date and is useful for interchange.
                  But you undermine that argument by indicating all significant vendors are using the method below, so adding NAD would break applications and require checking for two values (e.g. 0000-00-00 and NAD) to deal with the new standard and the legacy.
                   
                  It also says that you are trying to solve a problem that is already solved for most applications.
                   
                  You further argue that you need a high or low value. But given the examples you use, the consideration of high or low is well understood from the nature of the field being either a start or end, and so you undermine the argument more than one value is needed.
                   
                  It also seems this is all rehash, and I hope we are not going to spend the holiday weekend going thru essentially a rerun of a debate that has already been had. It seems you are describing at best some nice-to-haves, and not a flaw in the standard that justfies a change.
                   
                  tex


                  From: ISO8601@yahoogroups.com [mailto:ISO8601@yahoogroups.com] On Behalf Of hjwoudenberg@...
                  Sent: Friday, April 14, 2006 12:09 PM
                  To: ISO8601@yahoogroups.com
                  Subject: Re: [ISO8601] Re: Why three values of dates.

                  In a message dated 4/14/2006 8:29:23 A.M. Central Daylight Time, PIEBALDconsult@... writes:
                  How is that important? Because you say it's important? If the field
                  on a paper form is left blank or marked N/A or some such it's clear
                  what the meaning is.

                  With a bill of material you have two effective dates:
                   Part       Effective-from Effective-to
                   A           0000-00-00    9999-99-99
                  B            0000-00-00    2006-01-01
                  C            2006-01-01    9999-01-01
                   
                  If the effective dates are indexes to the bill-of-materials, than the retrieval for parts in 2006 will give part C, not part B.
                   
                  maybe you prefer searching through all the parts and testing each from and to date.
                   
                  Other and I don't.  I don;t think you will find any significant vendor who does not use this method.
                   
                  hjw
                • hjwoudenberg@aol.com
                  In a message dated 4/14/2006 2:39:53 P.M. Central Daylight Time, PIEBALDconsult@aol.com writes: Looks like a process-specific usage. Another process may want
                  Message 8 of 19 , Apr 15, 2006
                  • 0 Attachment
                    In a message dated 4/14/2006 2:39:53 P.M. Central Daylight Time, PIEBALDconsult@... writes:
                    Looks like a process-specific usage. Another process may want other
                    values. 
                    Everything can be a may.  The world may end tomorrow.  Do you have a example?
                    What is the heck is the problem you have with providing for it. You give the appearance you are against change.
                     
                    I have a locale common repository for local data for the same reason as W3C.  I have effective from and to dates like in a bill of material.  Therefore, when time zone rules change I but in effective dates.  Therefore, it will calculate the correct time when the new US time zone rules will take effect.  It will use different rules 
                     
                    The biggest disputes the IEEE-754 standard had was over infinity, NaN and zero.  I find our discussion parallel.
                     

                    W3C (World Wide Web Consortium) Web Services Task Force Common XML Locale Repository.

                    “The locale-dependant data that is used for date/time formatting, time zones, currencies; languages …etc often proves to be incorrect besides being inconsistent between systems.  Therefore, it is necessary a have a common repository for web services to access for locale information regardless of underlying platform, operating system, or software version.“

                  • hjwoudenberg@aol.com
                    Tex, you are the best. In a message dated 4/14/2006 2:51:50 P.M. Central Daylight Time, tex@yahoo-inc.com writes: Effectively you are using dates so far in
                    Message 9 of 19 , Apr 15, 2006
                    • 0 Attachment
                      Tex, you are the best.
                       
                      In a message dated 4/14/2006 2:51:50 P.M. Central Daylight Time, tex@... writes:
                      Effectively you are using dates so far in the past or future that they cannot possibly conflict with or be confused with actual dates used by your application.
                      You are correct.  My dates are more like binary low value (minimum binary value for a specific size integer) and max value. 
                       
                       
                      On the other hand, if the application were astronomy or world history those values would be problematic.
                      Because my software can process dates between -999999-01-01 and +999999-12-31, the display for these formats are 000000-00-00 and +999999-99-99.  Therefore the range expands for expanded years.  The zero month and day and the all nines month and day is the programming control. 
                       
                       
                      So on the one hand you could argue that NAD would define a value that all applications agree is not a date and is useful for interchange.
                      You have a good argument. In my consulting experience on the manufacturing industry, insurance industry and commodity industry, having a NaD condition to represent all three types of conditions worked.  Java, and even C have not implemented all of the floating point errors, because it is too difficult.  Therefore I simplified for these functions:
                      Compare        Difference        Change
                       
                      If one of the date values is 0000-00-00 or 9999-99-99 it is an error.
                       
                       
                       
                      But you undermine that argument by indicating all significant vendors are using the method below, so adding NAD would break applications and require checking for two values (e.g. 0000-00-00 and NAD) to deal with the new standard and the legacy.
                      Yes, until the IT industry gets a common method of handling errors, you have defined the problem precisely. 
                       
                       
                      It also says that you are trying to solve a problem that is already solved for most applications.
                      The solutions are proprietary.  I don't think they must be.
                       
                      You further argue that you need a high or low value. But given the examples you use, the consideration of high or low is well understood from the nature of the field being either a start or end, and so you undermine the argument more than one value is needed.
                      Yes, yes.
                       
                       
                      It also seems this is all rehash, and I hope we are not going to spend the holiday weekend going thru essentially a rerun of a debate that has already been had. It seems you are describing at best some nice-to-haves, and not a flaw in the standard that justfies a change.
                      If others have "Experience" with similar problems, good. 
                      You understand.  If some doesn't understand don't disagree. 
                       
                       
                       
                      tex

                       
                    • piebaldconsult
                      ... as W3C. ... Therefore, ... will ... effect. It ... I don t see how that applies to ISO 8601. It sounds like internal processing. (What I can make out if
                      Message 10 of 19 , Apr 15, 2006
                      • 0 Attachment
                        > I have a locale common repository for local data for the same reason
                        as W3C.
                        > I have effective from and to dates like in a bill of material.
                        Therefore,
                        > when time zone rules change I but in effective dates. Therefore, it
                        will
                        > calculate the correct time when the new US time zone rules will take
                        effect. It
                        > will use different rules


                        I don't see how that applies to ISO 8601. It sounds like internal
                        processing. (What I can make out if it.)
                      • piebaldconsult
                        ... give the ... A) Change just weighs down my pockets. B) I m only in favor of changes that _I_ propose. But seriously... 1) I m against changes that
                        Message 11 of 19 , Apr 15, 2006
                        • 0 Attachment
                          > What is the heck is the problem you have with providing for it. You
                          give the
                          > appearance you are against change.

                          A) Change just weighs down my pockets.
                          B) I'm only in favor of changes that _I_ propose.

                          But seriously...

                          1) I 'm against changes that broaden the scope of ISO 8601

                          1.1) Providing for undefined, non-temporal, or "fuzzy" values

                          1.2) Allowing textual timezone information

                          2) I am in favor of changes to ISO 8601 that reduce ambiguity

                          2.1) Disallowing truncated values as in :2004 (yay!)

                          2.2) Remove or deprecate "basic" format

                          2.3) Allow YYYY-MM-DDTHH and related formats

                          2.4) I realize that your NaD proposal would (to some extent)
                          reduce ambiguity, but 1.1 overrides it

                          The changes to ISO 8601 from :2000 to :2004 really seem to be
                          designed to ensure that only clearly defined values are represented.
                          The use of a time axis, means that _only_ values that indicate a
                          particular point or interval of the axis are to be represented.
                          (Except for a duration on its own.)

                          ISO 8601 also draws on other standards, take this to mean that
                          modularuty is a good thing, one should not try to define one standard
                          that covers _everything_. If there is a need (and perhaps there is)
                          for a standard of _internal_ representation and manipulation of
                          temporal data (including NaD and Infinity), then work to get that
                          done, but it should _not_ be part of ISO 8601.

                          Likewise, if part of your argument is that there should be a standard
                          for the textual interchange of floating point numbers, that that too
                          should be some other standard.
                        • hjwoudenberg@aol.com
                          In a message dated 4/15/2006 1:46:19 P.M. Central Daylight Time, PIEBALDconsult@aol.com writes: I don t see how that applies to ISO 8601. It sounds like
                          Message 12 of 19 , Apr 15, 2006
                          • 0 Attachment
                            In a message dated 4/15/2006 1:46:19 P.M. Central Daylight Time, PIEBALDconsult@... writes:
                            I don't see how that applies to ISO 8601. It sounds like internal
                            processing. (What I can make out if it.)

                            Another example of effective from and to effective dates.
                             
                            hjw
                          • hjwoudenberg@aol.com
                            In a message dated 4/15/2006 3:02:15 P.M. Central Daylight Time, PIEBALDconsult@aol.com writes: Likewise, if part of your argument is that there should be a
                            Message 13 of 19 , Apr 15, 2006
                            • 0 Attachment
                              In a message dated 4/15/2006 3:02:15 P.M. Central Daylight Time, PIEBALDconsult@... writes:
                              Likewise, if part of your argument is that there should be a standard
                              for the textual interchange of floating point numbers, that that too
                              should be some other standard.


                              Were you get this from.  I get the impression you want to misinterpret things.
                              These are examples.  Where are you coming from.
                               
                              Other reasons people don';t want to makes changes:
                                  I didn't think of it.
                                  I don't understand it.
                               
                              hjw
                              .
                            • Tex Texin
                              I would make a different argument. To be a standard for interchange, it must be usable for all applications. Herman has already stated his proposal meets the
                              Message 14 of 19 , Apr 15, 2006
                              • 0 Attachment
                                I would make a different argument.
                                To be a standard for interchange, it must be usable for all applications.
                                Herman has already stated his proposal meets the needs of his applications,
                                and not all.

                                A standard shouldn't stipulate that for some scenarios use 0000 and for
                                others use -999999 and for others use another value.

                                Also, one of the benefits of standards is that they protect your investment
                                in them. So iso 8601:2010 won't throw out all your applications based on
                                2004. Introducing a new value that is inconsistent with existing syntax, or
                                giving an old value new meaning or dual meanings (0000 is not a date and
                                also a legitimate year) will cause problems that can break legacy apps.

                                So changes to the standard should:
                                A) justify the cost of implementation for the majority of applications that
                                rely on the standard
                                B) Minimize breakage to existing applications and data.
                                C) be uniformly applied to allow ease of interchange.

                                Herman's proposal violates all of these criteria.
                                They are nice to haves, as the apps that need them already have solutions,
                                They would break existing apps,
                                They are not uniform and require at a minimum some agreement to be in place
                                for the values to be understood.
                                If an agreement is needed, why standardize? Let the parties decide for
                                themselves how to handle not-a-date.

                                For more on benefits of standards:
                                http://www.xencraft.com/resources/stdsbenefits.html


                                -----Original Message-----
                                From: ISO8601@yahoogroups.com [mailto:ISO8601@yahoogroups.com] On Behalf Of
                                piebaldconsult
                                Sent: Saturday, April 15, 2006 1:02 PM
                                To: ISO8601@yahoogroups.com
                                Subject: [ISO8601] Re: Why three values of dates.

                                > What is the heck is the problem you have with providing for it. You
                                give the
                                > appearance you are against change.

                                A) Change just weighs down my pockets.
                                B) I'm only in favor of changes that _I_ propose.

                                But seriously...

                                1) I 'm against changes that broaden the scope of ISO 8601

                                1.1) Providing for undefined, non-temporal, or "fuzzy" values

                                1.2) Allowing textual timezone information

                                2) I am in favor of changes to ISO 8601 that reduce ambiguity

                                2.1) Disallowing truncated values as in :2004 (yay!)

                                2.2) Remove or deprecate "basic" format

                                2.3) Allow YYYY-MM-DDTHH and related formats

                                2.4) I realize that your NaD proposal would (to some extent) reduce
                                ambiguity, but 1.1 overrides it

                                The changes to ISO 8601 from :2000 to :2004 really seem to be designed to
                                ensure that only clearly defined values are represented.
                                The use of a time axis, means that _only_ values that indicate a particular
                                point or interval of the axis are to be represented.
                                (Except for a duration on its own.)

                                ISO 8601 also draws on other standards, take this to mean that modularuty is
                                a good thing, one should not try to define one standard that covers
                                _everything_. If there is a need (and perhaps there is) for a standard of
                                _internal_ representation and manipulation of temporal data (including NaD
                                and Infinity), then work to get that done, but it should _not_ be part of
                                ISO 8601.

                                Likewise, if part of your argument is that there should be a standard for
                                the textual interchange of floating point numbers, that that too should be
                                some other standard.









                                Yahoo! Groups Links
                              • piebaldconsult
                                ... standard ... too ... misinterpret ... position
                                Message 15 of 19 , Apr 15, 2006
                                • 0 Attachment
                                  >> Likewise, if part of your argument is that there should be a
                                  standard
                                  >> for the textual interchange of floating point numbers, that that
                                  too
                                  >> should be some other standard.
                                  >>
                                  >
                                  > Were you get this from. I get the impression you want to
                                  misinterpret
                                  > things.

                                  Because of your statement:

                                  > If the IT Industry does not do this it will find itself in the same
                                  position
                                  > the floating point industry is today.
                                • hjwoudenberg@aol.com
                                  In a message dated 4/15/2006 7:41:11 P.M. Central Daylight Time, PIEBALDconsult@aol.com writes: If the IT Industry does not do this it will find itself in
                                  Message 16 of 19 , Apr 15, 2006
                                  • 0 Attachment
                                    In a message dated 4/15/2006 7:41:11 P.M. Central Daylight Time, PIEBALDconsult@... writes:
                                    If the IT Industry does not  do this it will find itself in the same
                                    position
                                    > the floating point industry is  today.



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