Hello Andreas,Ok, I'm convinced.On 6/20/06, Andreas Junghans <[EMAIL PROTECTED]> wrote:
[...]Now let's see what we'd gain from using ISO dates:- It's more standard.
- It's (a little) easier to parse on the server.[...]Although probably still not enough to warrant a change, there's one more:- It pro
Hi Danny,
Am 20.06.2006 um 04:59 schrieb Danny Adair:
>> But as Andreas stated, what's important is not the server, it's
>> the client.
>> We must do anything reasonable that we can to make the client-side
>> processing
>> as fast as possible.
>
> You seem to have two reasons for sticking wit
Removed a superfluous check and shortened the microseconds->milliseconds statementOn 6/20/06, Danny Adair <
[EMAIL PROTECTED]> wrote:Sorry,I used a crappy editor and needed to make some tab->space conversions.
Also added some comments about possible future improvements, and a test for an 1870 datet
Sorry,I used a crappy editor and needed to make some tab->space conversions.Also added some comments about possible future improvements, and a test for an 1870 datetime.Kind regards,--
Danny W. AdairDirectorUnfold LimitedNew ZealandTalk: +64 4 472 1679Fax:+64 4 472 1680Write: [E
Hello Derrell,All I wanted to say was that there's creating and parsing. My proposed approach would need one function each way.
Your current method does not need a function for parsing, but still for creating the string representation. If you have to put in this extra step anyway, why not stick to
Andreas Junghans <[EMAIL PROTECTED]> writes:
> Sorry for belaboring the issue ;-)
Well I can belabor too. :-) But I wont, in this case. They'll be utility
functions. Applications that want them can use them. I don't expect to put
up any complaint about you adding them as long as they don't im
Hi Derrell,
Am 19.06.2006 um 16:06 schrieb [EMAIL PROTECTED]:
> Andreas Junghans <[EMAIL PROTECTED]> writes:
>
>> Where's the difference between
>> qx.core.ServerSettings.serverPathPrefix and
>> qxrpc_serverPathPrefix (apart from the global namespace pollution
>> of the
>> latter)?
>
> Hi A
[EMAIL PROTECTED] writes:
>> I just tested moving the instanceId to the URL, and it works fine, so I
>> don't have a problem with that. To support this model, the makeServerURL
>> function discussed above would get an additional optional parameter for the
>> instance id. This looks like a good sol
Andreas Junghans <[EMAIL PROTECTED]> writes:
> Where's the difference between qx.core.ServerSettings.serverPathPrefix and
> qxrpc_serverPathPrefix (apart from the global namespace pollution of the
> latter)?
Hi Andreas,
There's no difference except that one method puts code into qooxdoo that i
Hi Derrell,
>> The important point is that including ".qxrpc" fills in some internal
>> qooxdoo structure with the settings of the current server (i.e.
>> the server
>> where the HTML page came from).
>
> Ok, I think I see how you're using this, but I wonder if it belongs
> in qooxdoo
> at all, or
"Danny Adair" <[EMAIL PROTECTED]> writes:
> Sorry, I think there's a misunderstanding.
> Of course you can construct "new Date(Date.UTC(2006,6,16,3,53,27))" but you
> will use a (qooxdoo) helper function to do this, in JavaScript something
> like
> return 'new Date(Date.UTC(' + d.getUTCFullYear()
By the way, the best ISO8601 functions I could find started at http://delete.me.uk/2005/03/iso8601.html
and are now part of
http://archive.dojotoolkit.org/nightly/src/date.jsI had a look around, and everyone (including the examples on
json.org) elegantly omits Date objects in JSON. :-)Various wo
Hello Derrell,On 6/17/06, [EMAIL PROTECTED]
<
[EMAIL PROTECTED]> wrote:[...]> On the server side "isoTimestamp('2006-06-16T03:53:27Z')" (yes the client
> can eval this - through qooxdoo), is at least as easy to parse as "new Date(> Date.UTC(2006,6,16,3,53,27))". I left out milliseconds here.If one
Andreas Junghans <[EMAIL PROTECTED]> writes:
> Sounds good, but I'd like to check first if it's easy to implement in Java
> (the problem I see is getting an additional query parameter from the URL
> when the request method is POST and the body is not form- encoded). It would
> be great if you coul
"Danny Adair" <[EMAIL PROTECTED]> writes:
> a) If you want to stick to the second paragraph (note how that one says "is"
> instead of "is based on" a subset of JavaScript), you might as well use
> Javascript's ugly string representation, which provides a roundtrip (and
> timezone info):
>var d
Sorry,I can't help it. :-)There seems to be a dilemma in regards to consistency of dates:Compare the first parargaph of
http://www.json.org:"JSON (_javascript_ Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and g
Andreas Junghans <[EMAIL PROTECTED]> writes:
> Come on, it's not that hard! You simply have to treat the start and end of a
> date the same way you treat the quotes for strings.
>
> Attached is a patch to your JSON parser that does exactly that.
Yup, after a comment like mine, I deserved this. :-
Hi Derrell,
Am 16.06.2006 um 03:31 schrieb [EMAIL PROTECTED]:
If it's feasible to do, I would like to at least have the ability
to have the
same format going both directions. I'll let you know the results.
I just saw your message directly after I sent mine :-) However, it
seems I had fo
Hi Derrell,
Am 16.06.2006 um 00:59 schrieb [EMAIL PROTECTED]:
> Andreas Junghans <[EMAIL PROTECTED]> writes:
>
>> I would greatly prefer a single, standard format, no matter in which
>> direction a date is sent.
>> ...
>> Since it's so difficult to properly handle timestamps in PHP (and
>> mayb
[EMAIL PROTECTED] writes:
> Andreas Junghans <[EMAIL PROTECTED]> writes:
>
>> I would greatly prefer a single, standard format, no matter in which
>> direction a date is sent. ... Since it's so difficult to properly handle
>> timestamps in PHP (and maybe other backends too), I suggest we standar
Andreas Junghans <[EMAIL PROTECTED]> writes:
> I would greatly prefer a single, standard format, no matter in which
> direction a date is sent.
> ...
> Since it's so difficult to properly handle timestamps in PHP (and maybe
> other backends too), I suggest we standardize on the second syntax: new
Hi Derrell,
Am 15.06.2006 um 04:00 schrieb [EMAIL PROTECTED]:
> What I ended up doing was using the ISO-8601 format for
> transmission *to* the
> server. It's currently encapsulated in a "new Date( string>)" but
> possibly needn't be. There does need to be something that
> identifies it as
22 matches
Mail list logo
