[JDEV] Timezone (summary)

Isotope2k at aol.com Isotope2k at aol.com
Mon Oct 11 11:30:39 CDT 1999


First off, I certainly hope that my last post wasn't considered a
_dumb_ post.  I'm only trying to help, and I certainly don't feel
that it was noise.

>We're not assuming instantaneous delivery. Just fast.
>I would also like to point ou the example of an "archived" message

I put the word in quotes for that very reason.  An archived message
is a very good example of a situation that breaks the mechanism,
so I'll dump the idea, my apologies.

>We cannot assume TCP/IP and "normal" timestamping. Jabbertransport uses
>TCP/IP and that's the extent of the reliablity issue we can go. etherx uses
>TCP/IP, true, but udpx or 6782x might not.

Again, my apologies, I thought TCP/IP could be assumed.  This brings up 
another
issue for me though, and that is, what if a closed network runs IPX or some 
not
yet conceived protocol?  Should we perhaps add a layer of abstraction in those
codebases to seperate the delivery mechanism?  Just a thought.  I do realise 
this
would add a significant amount of overhead.

>What is "normal" timestamping, also? There is no timestamp on a normal
>message at this point.

I meant "normal" to refer to a timestamp which lacks timezone information.

>> UNLESS the sender is traversing timezones between messages.
>Happens to me. Happened to jer. It happens all the time.

How then can we rely on any timezone information supplied by the client?

>> I think it would be useful if we constructed this discussion in a more 
>> high-level manner.
>Already have. You're just reiterating.

Taken as a whole, I suppose we have.  My hope was that we
could do it in a clearer, more intuitive manner.  Perhaps my reiteration
(and Waleed's summaries) was an attempt in that direction.  Clearly restating
the issues has been very useful to me in the past in eliminating redundant
discussions and streamlining decision making.  Upon re-reading your proposal
I can see that we are futher along than I thought.  Again, my apologies are 
due
for contributing to redundancy.

Back to lurker mode...

Christopher Atkins




More information about the JDev mailing list