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

Re: [json] Why we have to waist our time for Date parsing?

Expand Messages
  • Mark Joseph
    So these JSON parse functions for Dates are just utility functions available for use to help parse data in Javascript? What purpose does this discussion
    Message 1 of 33 , Aug 7, 2009
    • 0 Attachment
      So these JSON parse functions for Dates are just utility functions available for use to help parse data in Javascript? What purpose does this discussion have with the JSON standard?

      Best,
      Mark



      From: Andrea Giammarchi [mailto:andrea.giammarchi@...]
      To: json@yahoogroups.com
      Sent: Fri, 07 Aug 2009 05:38:07 -0700
      Subject: [json] Why we have to waist our time for Date parsing?






      JSON.parse function accepts an extra argument which main usage is to
      transform strings into Dates, if encountered.
      For performances reason this operation will cost a callback for each item to
      "walk", a regexp check for each string encountered in each item, eventually
      the creation of a new Date(Date.UTC(arguments ... )) to return.

      All this stuff could be simplified simply adding this piece of code the
      instant it is evaluated:

      // fast date regeneration via ISO RegExp from WebReflection
      j = eval('(' + text.replace(

      /(^|[:,\[])"(\d{4})(-(\d{2})(-(\d{2})(T(\d{2}):(\d{2})(:(\d{2})(\.(\d+))?)?(Z|((\+|-)(\d{2}):(\d{2}))))?)?)?"/g,
      "$1new Date(Date.UTC($2,$4-1,$6,$8,$9,$11,$13+0))"
      ) + ')');

      Performance speaking, it is not possible to compare the real gap between
      this solution and the "manual one" 'cause more date objects we have, more
      this solution will make the difference and the operation fast.

      The problem is that every native JSON.parse will not accept a transformed
      string before its call so in these browsers we need to convert manually. It
      is possible in any case to test, at least, the JSON string in orther to
      understand if the Date parsing is required.

      JSON.parse = (function(parse){
      return function(value){
      var transformDates = aboveISORegExp.test(value);
      value = parse.call(JSON, value);
      if(transformDates)
      walk(value, function(str){ ... the callback to check and transform
      str in Date ... })
      };
      })(JSON.parse);

      I would like to know your opinion about this, thanks.

      Regards

      [Non-text portions of this message have been removed]




      [Non-text portions of this message have been removed]
    • Martin Cooper
      On Wed, Aug 12, 2009 at 10:15 AM, Andrea Giammarchi
      Message 33 of 33 , Aug 12, 2009
      • 0 Attachment
        On Wed, Aug 12, 2009 at 10:15 AM, Andrea Giammarchi <
        andrea.giammarchi@...> wrote:

        > I have created dunno how many JSON open source parsers but json2.js is
        > apparently frequently updated and being the "unofficial" standard adopted
        > by
        > most recent browsers tell me why "we", as developers, should put effort for
        > something that is already defined elsewhere where posts like "please
        > consider this feature" are not considered at all (neither welcome)


        I think you just answered your own question. The reason you, or I, or
        someone else, would create a project on, say, Google Code, for a new JSON
        implementation is precisely so that posts like "please consider this
        feature" *are* considered.

        As for creating a project separate, and different, from the "unofficial"
        standard, there are numerous cases of open source alternatives to reference
        implementations, including cases in which the alternatives have become at
        least as widely used as the RIs themselves.

        --
        Martin Cooper



        > On Wed, Aug 12, 2009 at 5:26 PM, Martin Cooper <mfncooper@...>
        > wrote:
        >
        > >
        > >
        > > Fang is correct that there is no "official" JSON parser, and also that
        > > json2.js could be considered a reference implementation (RI).
        > >
        > > Since Douglas unilaterally controls this RI, it is only ever going to
        > > include what is in the JSON specification, or what Douglas perceives will
        > > become part of a future version of that specification.
        > >
        > > More than once, I've considered taking the code from json2.js (which is
        > > Public Domain, after all), creating an open source project out of it, and
        > > enhancing it to do things a bit differently and / or add capabilities
        > that
        > > I've seen a need for and people have expressed a desire for. It's my
        > > impression that so many people use json2.js simply because it's there and
        > > because nobody has gone ahead and forked it into a more complete library.
        > > Why have I not done that? Honestly, just laziness up to now. It's not
        > like
        > > I
        > > haven't done open source before. ;-)
        > >
        > > --
        > > Martin Cooper
        > >
        > >
        > > On Wed, Aug 12, 2009 at 12:06 AM, Andrea Giammarchi <
        > > andrea.giammarchi@... <andrea.giammarchi%40gmail.com>> wrote:
        > >
        > > > OK guys, I've got your point.
        > > >
        > > > About "dictating" it was what Douglas said: ES5 and every browser are
        > > going
        > > > to implement json2.js serializer/unserializer API.
        > > > JSON is basically JavaScript "quirk" syntax, eval without modifications
        > > > indeed, it comes from ECMAScript specs, and it uses string transformed
        > > from
        > > > Unicode, again JavaScript natural strings encoding.
        > > >
        > > > I thought this mailing list was not only about the protocol, but about
        > > > everything around it, parsers included, I was obviously wrong.
        > > >
        > > > If you manage JSON via server side languages and/or for databases does
        > > not
        > > > change that much the fact dates are a lost transformations.
        > > >
        > > > Again, I never thought about changing JSON protocol as is, I just
        > > > considered
        > > > there is a Date unofficial convention, every parser manages it, which
        > > does
        > > > not come back Dates and I suggested a parser
        > modification/implementation
        > > > that cannot break or change the JSON protocol itself at all.
        > > >
        > > > It is easy for me to change the json2.js file as is to add a method in
        > > > browsers JSON object but obviously if it was something discussed and
        > > > implemented, I am talking about parseISO or whatever name you prefer,
        > it
        > > > would have been good for everybody, without breaking what we have so
        > far,
        > > > and simply adding a common transformation back parser method for every
        > > > language.
        > > >
        > > > Best Regards
        > > >
        > > >
        > > > [Non-text portions of this message have been removed]
        > > >
        > > >
        > > >
        > > > ------------------------------------
        > > >
        > > > Yahoo! Groups Links
        > > >
        > > >
        > > >
        > > >
        > >
        > > [Non-text portions of this message have been removed]
        > >
        > >
        > >
        >
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >


        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.