[JDEV] Timezone (summary)

[Scott Robinson]

Interleaved response.

Scott.

* Isotope2k at aol.com translated into ASCII [Mon, Oct 11, 1999 at 11:26:27AM -0400][<0.ced12ad4.25335ba3 at aol.com>]
[snap]
> 1)  Timezone information could be used by the client to give the receiver
> the ability to know what time the sender sent the message.
> 2)  Timezone information could be used by server the asses efficiency in
> messaging routing.
> 3)  Timezone information could be used by the client to sort messages 
> according
> to some sender-time based scheme.
> 
> Are the benefits described above already available to us through alternate 
> means?
> 
> 1)  Assuming the "instantaneous" delivery of Jabber messages (IM afterall) and
> assuming that our choice of timestamp format allows for such calculations (as
> all three proposals do) timezone information can be extracted from timestamp
> by comparing local time to the timestamp and deriving the +/- GMT shifts.
>   Admittedly, this is a bit kludgy.  However, many of the problems associated 
> with
> this message (such as fast/slow local/remote clocks, lack of local timezone 
> info)
> are present with the alternative of including timezone information.  
> Futhermore,
> this method requires more work to be done by the client.
> 

We're not assuming instantaneous delivery. Just fast.

I would also like to point ou the example of an "archived" message.

> 2)  TCP/IP and "normal" timestamping both allow for efficiency assessment.
> 

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.

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

> 3)  Generally, the human user's client (to whom this kind of time relativity 
> is probably
> exclusive of interest to), will organize senders in a "buddy list" of sorts, 
> and as such
> this kind of sorting would be done on a per-sender basis, and thus timezone 
> info would
> be of little use- UNLESS the sender is traversing timezones between messages.
> 

Happens to me. Happened to jer. It happens all the time.

> I think it would be useful if we constructed this discussion in a more 
> high-level 
> manner (such as this).  Let's decide if, and how, the timezone information 
> would be
> useful, and then ensure that the uses aren't already covered, and THEN drill 
> down to 
> possible implementations.
> 

Already have. You're just reiterating.

> Conclusion:
> Inclusion of timezone information is of primary (exclusive?) use to human 
> clients
> in order to determine the relative local time of the sender.  As such, this 
> information
> should be optional (I believe that is the general concensus).  There are 
> alternative(s) 
> to determining this data that do not require the addition of timezone 
> information, thus
> I feel that it is not necessary to add this to the project.  If a client 
> wishes to make
> this information available to the user, it is not necessary for Jabber to 
> supply it.
> 

We are not forcing Jabber to supply it. The current message-level routing
proposal is easily maskable (since it's XML) and doesn't have a requirement
of implementation.

> I eagerly await futher discussion.
> 
> Christopher Atkins
[snap]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/19991011/bec5d1c9/attachment-0002.pgp>