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

RE: [json] json date format 2006-12-03T13:56:21

Expand Messages
  • Gaetano Giunta
    afaik, jsonrpc uses a variant of ISO without millliseconds. also, for most databases, the standard date and time fields omit milliseconds (a timestamp value is
    Message 1 of 12 , Dec 5, 2006
    • 0 Attachment
      afaik, jsonrpc uses a variant of ISO without millliseconds.
      also, for most databases, the standard date and time fields omit milliseconds (a timestamp value is used for that)


      -----Original Message-----
      From: json@yahoogroups.com [mailto:json@yahoogroups.com]On Behalf Of Peter Michaux
      Sent: Sunday, December 03, 2006 11:38 PM
      To: json@yahoogroups.com
      Subject: Re: [json] json date format 2006-12-03T13:56:21


      Hi Martin,

      On 12/3/06, Martin Cooper <mfncooper@...> wrote:
      >
      > On 12/3/06, Peter Michaux <petermichaux@...> wrote:

      > >
      > > A date object is converted to the following format
      > >
      > > 2006-12-03T13:56:21
      > >
      > > Is this an international standard time representation?
      >
      > Yep. It's defined by ISO 8601. There's a summary of that here:
      >
      > http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html

      Thanks for the link

      > I don't think it has a provision for milliseconds, but I could be wrong.

      It looks like it does. From that link

      The standard has provisions for:
      (1) the omission of components representing smaller units
      (seconds, minutes), where such precision is not needed,
      (2) the addition of a decimal fraction to the smallest time unit
      where higher precision is needed.

      Perhaps the Json code could be changed to

      return '"' + x.getFullYear() + '-' +
      f(x.getMonth() + 1) + '-' +
      f(x.getDate()) + 'T' +
      f(x.getHours()) + ':' +
      f(x.getMinutes()) + ':' +
      f(x.getSeconds()) + '.' +
      f(x.getMilliseconds()) + '"';

      There could be other reasons for excluding the milliseconds. Perhaps
      some of the systems with which json is intended to facilitate data
      transmission cannot handle milliseconds?

      Thanks,
      Peter




      [Non-text portions of this message have been removed]
    • Peter Michaux
      ... Douglas, is there a particular reason for not including milliseconds in json.js? Thanks, Peter -- Fork JavaScript: http://forkjavascript.org
      Message 2 of 12 , Jan 6, 2007
      • 0 Attachment
        On 12/4/06, Peter Michaux <petermichaux@...> wrote:
        >
        > This is what I was thinking. Milliseconds could be important at times
        > and seems unfortunate to throw them out if there is no reason.

        Douglas, is there a particular reason for not including milliseconds in json.js?

        Thanks,
        Peter
        --
        Fork JavaScript: http://forkjavascript.org
      • Douglas Crockford
        ... in json.js? You have the source, you can put them in any time you want to. But first, let me ask you a question: How confident that your system s clock has
        Message 3 of 12 , Jan 6, 2007
        • 0 Attachment
          > Douglas, is there a particular reason for not including milliseconds
          in json.js?

          You have the source, you can put them in any time you want to. But
          first, let me ask you a question: How confident that your system's
          clock has millisecond accuracy? And that the latency of the OS +
          Browser + JavaScript will not cause significant drift by the time it
          is delivered to your application? How meaningful will the milliseconds
          be when you put them on the wire and send them to your server, whose
          clock is not in sync with yours? Milliseconds are a waste of time.

          There are applications, such as video editing, where subsecond
          accuracy is important. If you have such an application, then you would
          want to tack on frames or fractional seconds. If you don't really need
          it, then it is better to not deceive yourself with false precision.
        • Peter Michaux
          ... I m sorry for bothering you, sir. Thank you for your answer. I ll go back to my corner now. Peter
          Message 4 of 12 , Jan 6, 2007
          • 0 Attachment
            On 1/6/07, Douglas Crockford <douglas@...> wrote:
            >
            > > Douglas, is there a particular reason for not including milliseconds
            > in json.js?
            >
            > You have the source, you can put them in any time you want to. But
            > first, let me ask you a question: How confident that your system's
            > clock has millisecond accuracy? And that the latency of the OS +
            > Browser + JavaScript will not cause significant drift by the time it
            > is delivered to your application? How meaningful will the milliseconds
            > be when you put them on the wire and send them to your server, whose
            > clock is not in sync with yours? Milliseconds are a waste of time.

            I'm sorry for bothering you, sir. Thank you for your answer. I'll go
            back to my corner now.

            Peter
          • Peter Michaux
            ... A date object is not necessarily constructed with no arguments sent to the Date constructor. It could very well be that in some applications the
            Message 5 of 12 , Jan 10, 2007
            • 0 Attachment
              On 1/6/07, Douglas Crockford <douglas@...> wrote:
              >
              > > Douglas, is there a particular reason for not including milliseconds
              > in json.js?
              >
              > You have the source, you can put them in any time you want to. But
              > first, let me ask you a question: How confident that your system's
              > clock has millisecond accuracy? And that the latency of the OS +
              > Browser + JavaScript will not cause significant drift by the time it
              > is delivered to your application? How meaningful will the milliseconds
              > be when you put them on the wire and send them to your server, whose
              > clock is not in sync with yours? Milliseconds are a waste of time.

              A date object is not necessarily constructed with no arguments sent to
              the Date constructor. It could very well be that in some applications
              the construction of the Date object could use date data from a user
              input which has very accurate and critical milliseconds information
              from another very accurate system.

              Peter
            • geoffreyk00
              ... milliseconds ... But ... system s ... time it ... milliseconds ... whose ... time. ... sent to ... applications ... The date object may be historical data
              Message 6 of 12 , Jan 11, 2007
              • 0 Attachment
                --- In json@yahoogroups.com, "Peter Michaux" <petermichaux@...>
                wrote:
                >
                > On 1/6/07, Douglas Crockford <douglas@...> wrote:
                > >
                > > > Douglas, is there a particular reason for not including
                milliseconds
                > > in json.js?
                > >
                > > You have the source, you can put them in any time you want to.
                But
                > > first, let me ask you a question: How confident that your
                system's
                > > clock has millisecond accuracy? And that the latency of the OS +
                > > Browser + JavaScript will not cause significant drift by the
                time it
                > > is delivered to your application? How meaningful will the
                milliseconds
                > > be when you put them on the wire and send them to your server,
                whose
                > > clock is not in sync with yours? Milliseconds are a waste of
                time.
                >
                > A date object is not necessarily constructed with no arguments
                sent to
                > the Date constructor. It could very well be that in some
                applications
                > the construction of the Date object could use date data from a user
                > input which has very accurate and critical milliseconds information
                > from another very accurate system.
                >
                > Peter
                >

                The date object may be historical data that truly is millisecond-
                accurate. The object does not have to be constructed when the
                dataset is created or by the server that is delivering the dataset.
                I more likely will have been created long before, with many date
                objects that do need this level of accuracy.

                I can see no reason to not to include milliseconds, and many reasons
                to keep them.
              Your message has been successfully submitted and would be delivered to recipients shortly.