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

Re: Introduction Date and Function objects to the standard [DATE PARSER]

Expand Messages
  • Greg Patnude
    It is originally based on converting a date-time string from an ANSI SQL database into a JavaScript UTC time... The ANSI SQL datetime (timestamp) appeared to
    Message 1 of 18 , May 26, 2006
    • 0 Attachment
      It is originally based on converting a date-time string from an ANSI
      SQL database into a JavaScript UTC time... The ANSI SQL datetime
      (timestamp) appeared to be "closest to" the JavaScript Date()
      constructor at the time I developed the library --

      var dt = new Date("mm-dd-yy hh:mm:ss.ms");


      Since 99.999% of the dates / times I display in the UI come from the
      RDBMS -- this also made a lot of sense at the time....

      RE: Unix date / time -- not everyone is into Unix... many people
      appear to be using PHP, Perl, and ASP... Personally -- if it were
      100% Unix / C / Java / ANSI SQL types -- I would be a happy camper...
      but... we gotta provide support for the greatest common
      denominator... not the lowest common denominator...



      --- In json@yahoogroups.com, Christopher Stumm <christopher@...>
      wrote:
      >
      > On 26 May, 2006, at 12:31, Martin Cooper wrote:
      >
      > > On 5/26/06, Greg Patnude <gpatnude@...> wrote:
      > > >
      > > > I have a JSON compatible date parser which converts a
      stringified
      > > > version of a C-Type date (mm-dd-yyyy hh:mm:ss.nnnn [AM:PM])
      into a
      > > > JavaScript native Date object format...
      > >
      > > Why the C format? Why not base it on the ISO standard, if we
      have to
      > > include
      > > dates in JSON? And if the above format actually defines what you
      > > have, then
      > > how would I specify the time zone? Or is it assumed to be UTC?
      >
      > Maybe I'm missing something, but why wouldn't one simply use the
      > standard
      > unix time? It does not rely on time-zones (which people seem to
      largely
      > ignore
      > on the internet), and is likely supported already by most
      languages, JS
      > included.
      > In addition it can easily be sent around as a simple int.
      >
      > -Christopher
      >
    • Fang Yidong
      It s not necessary to add Date SPEC to JSON to make things work. JSON just give you the freedom to do whatever you want. I ve used JSON.simple to exchange
      Message 2 of 18 , May 26, 2006
      • 0 Attachment
        It's not necessary to add Date SPEC to JSON to make
        things work. JSON just give you the freedom to do
        whatever you want.

        I've used JSON.simple to exchange millions of records
        contains date and time fields from Oracle to
        Postgres,it works very well and just 2 or 3 lines
        added to convert the date and time format between
        Oracle and Postgres,without the Date SPEC.

        So I think the core primitive datetype
        String,True,False,Number and Null of JSON is enough.

        --- Greg Patnude <gpatnude@...>:

        > It is originally based on converting a date-time
        > string from an ANSI
        > SQL database into a JavaScript UTC time... The ANSI
        > SQL datetime
        > (timestamp) appeared to be "closest to" the
        > JavaScript Date()
        > constructor at the time I developed the library --
        >
        > var dt = new Date("mm-dd-yy hh:mm:ss.ms");
        >
        >
        > Since 99.999% of the dates / times I display in the
        > UI come from the
        > RDBMS -- this also made a lot of sense at the
        > time....
        >
        > RE: Unix date / time -- not everyone is into Unix...
        > many people
        > appear to be using PHP, Perl, and ASP... Personally
        > -- if it were
        > 100% Unix / C / Java / ANSI SQL types -- I would be
        > a happy camper...
        > but... we gotta provide support for the greatest
        > common
        > denominator... not the lowest common denominator...
        >
        >
        >
        > --- In json@yahoogroups.com, Christopher Stumm
        > <christopher@...>
        > wrote:
        > >
        > > On 26 May, 2006, at 12:31, Martin Cooper wrote:
        > >
        > > > On 5/26/06, Greg Patnude <gpatnude@...> wrote:
        > > > >
        > > > > I have a JSON compatible date parser which
        > converts a
        > stringified
        > > > > version of a C-Type date (mm-dd-yyyy
        > hh:mm:ss.nnnn [AM:PM])
        > into a
        > > > > JavaScript native Date object format...
        > > >
        > > > Why the C format? Why not base it on the ISO
        > standard, if we
        > have to
        > > > include
        > > > dates in JSON? And if the above format actually
        > defines what you
        > > > have, then
        > > > how would I specify the time zone? Or is it
        > assumed to be UTC?
        > >
        > > Maybe I'm missing something, but why wouldn't one
        > simply use the
        > > standard
        > > unix time? It does not rely on time-zones (which
        > people seem to
        > largely
        > > ignore
        > > on the internet), and is likely supported already
        > by most
        > languages, JS
        > > included.
        > > In addition it can easily be sent around as a
        > simple int.
        > >
        > > -Christopher
        > >
        >
        >
        >
        >
        >
        >
        > ------------------------ Yahoo! Groups Sponsor
        > --------------------~-->
        > Home is just a click away. Make Yahoo! your home
        > page now.
        >
        http://us.click.yahoo.com/DHchtC/3FxNAA/yQLSAA/1U_rlB/TM
        >
        --------------------------------------------------------------------~->
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        > json-unsubscribe@yahoogroups.com
        >
        >
        >
        >
        >



        ___________________________________________________________
        JSON: Action in AJAX!

        JSON - http://www.json.org
        JSON.simple - http://www.json.org/java/simple.txt




        ___________________________________________________________
        雅虎免费邮箱-3.5G容量,20M附件
        http://cn.mail.yahoo.com/
      • Lindsay
        ... Agreed. I d like to see a std for dates as they are very commonly used and nearly count as a scalar type :) But stick to the KISS principle. Feature bloat
        Message 3 of 18 , May 28, 2006
        • 0 Attachment
          Dave Balmer wrote:
          > Greg,
          >
          > I've given this a bit of thought too, but in the end this would only
          > complicate matters exponentially. Making a simple data parser is one
          > thing, but adding in a language parser (much less many language
          > parsers) on top of that just isn't practical.
          >

          Agreed. I'd like to see a std for dates as they are very commonly used
          and nearly count as a scalar type :) But stick to the KISS principle.
          Feature bloat his killed a lot of stds.


          --
          Lindsay
        • Kevin Smith
          ... I completely agree. We were unable to use the GNOTE-licensed code in either our GPL application, or in our other app that s currently closed-source.
          Message 4 of 18 , Jun 3, 2006
          • 0 Attachment
            --- In json@yahoogroups.com, "Martin Cooper" wrote:
            >
            > On 5/26/06, Greg Patnude <gpatnude@...> wrote:
            > >
            > > Speaking of the "Good NOT Evil" license -- is anyone interested in
            > > formalizing that ? like the myriad licensing already available --
            > > GPL, or LGPL, or BSD Licenses... we could call it the "GNOTE"
            > > license....
            >
            >
            > No, no, no! There are already dozens and dozens of open source
            > licenses. There is absolutely no good reason to invent another one.
            > Do you have any idea how much legal crap creating a new license
            > creates for any company or other organisation that actually wants
            > to use the associated software?

            I completely agree. We were unable to use the GNOTE-licensed code in
            either our GPL application, or in our other app that's currently
            closed-source. Fortunately, we found a json implementation under a
            simpler license, so we didn't have to re-invent it from scratch.

            Personally, my big problem with the GNOTE license is: WHO decides what
            is evil? Some folks thing gays are evil, while others think that
            anti-gay behavior is evil. Some folks think Bin Laden is evil, but
            I'm pretty sure he thinks his enemies are the evil ones. Worse...what
            is "evil" can change over time, so I might be allowed to use the
            software today, but next year my use might be considered evil by the
            license holder.

            It's a great idea, but just doesn't work in practice. Basically, it
            will either discourage people from using the software, or will
            encourage people to ignore or violate the license, whether
            intentionally, or due to a disagreement over what is evil. Pretty much
            anyone who takes licenses seriously will not be able to use GNOTE
            software.

            > I'd suggest the Apache License 2.0, which pretty much says you can
            > do whatever you want with the software as long as you keep the
            > original license in place.

            Except that Apache License 2.0 code (arguably) can't be linked with
            GPL software, which is unfortunate. For widest compatibility with
            other licenses, I prefer the MIT-style license, which is even more
            liberal. The LGPL also tends to work well with proprietary and Free
            software.

            Kevin
          • Michal Migurski
            ... Except for time zones. ... As another poster commented, unix epoch is a great transmission format thanks to its explicit treatment of time zones. Every
            Message 5 of 18 , Jun 3, 2006
            • 0 Attachment
              > var dt = new Date("mm-dd-yy hh:mm:ss.ms");
              >
              >
              > Since 99.999% of the dates / times I display in the UI come from the
              > RDBMS -- this also made a lot of sense at the time....

              Except for time zones.

              > RE: Unix date / time -- not everyone is into Unix... many people
              > appear to be using PHP, Perl, and ASP... Personally -- if it were
              > 100% Unix / C / Java / ANSI SQL types -- I would be a happy camper...
              > but... we gotta provide support for the greatest common
              > denominator... not the lowest common denominator...

              As another poster commented, unix epoch is a great transmission
              format thanks to its explicit treatment of time zones. Every language
              I deal with in my work uses it (PHP, Python, ECMA-, Action-, and
              JavaScript in milliseconds), and I find it vastly preferable when
              moving data between web servers, DB servers, and client browsers that
              are in unknown locations. The Atom spec does something similar, by
              requiring dates to be expressed in UTC.

              I'm generally opposed to the inclusion of dates and functions into
              javascript, though. Python has four ways to describe dates, and PHP
              limits what can be done with functions as data. No sense in taking a
              simple, beautiful spec and complicating it just to satisfy a few edge
              cases.

              -mike.

              ----------------------------------------------------------------
              michal migurski- contact info and pgp key:
              sf/ca http://mike.teczno.com/contact.html
            • Martin Cooper
              ... ... No, that s not the case (and there is no arguably ;), at least from an ASF perspective. There is a policy in place at the Apache Software
              Message 6 of 18 , Jun 6, 2006
              • 0 Attachment
                On 6/3/06, Kevin Smith <yahoogroups@...> wrote:
                >
                > --- In json@yahoogroups.com, "Martin Cooper" wrote:


                <snip/>

                > I'd suggest the Apache License 2.0, which pretty much says you can
                > > do whatever you want with the software as long as you keep the
                > > original license in place.
                >
                > Except that Apache License 2.0 code (arguably) can't be linked with
                > GPL software, which is unfortunate.


                No, that's not the case (and there is no "arguably" ;), at least from an ASF
                perspective.

                There is a policy in place at the Apache Software Foundation (ASF) that
                states that ASF projects cannot have required dependencies on, or bundle,
                libraries licensed under the GPL or certain other licenses. What that means
                is that whenever you download ASF software, you can be absolutely sure that
                there are no "tricks up our sleeve" and you do not suddenly find yourself
                using additional software, with incompatible licenses, that you may not have
                expected.

                That is _completely_ different from what you, as a user of ASF software,
                choose to do with it. If you want to build an application that includes ASF
                and GPL software, that is absolutely fine with the ASF.

                For widest compatibility with
                > other licenses, I prefer the MIT-style license, which is even more
                > liberal. The LGPL also tends to work well with proprietary and Free
                > software.


                I'd agree that the MIT license is very flexible, but I'd suggest caution
                with the LGPL in a business environment. But this is getting way off-topic
                for this list...

                --
                Martin Cooper


                Kevin
                >
                >
                >
                >
                >
                >
                >
                >
                > 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.