Mailing List Archive

Blake Mitchell wrote:

> So what would be involved in getting dbmail to do time zones? My mail
> server is 3 time zones away, and all my received date are three hours off.
I've been looking at this before, but I was a bit confused on how the
IMAP server should implement it. As I understand it, the server should
store the messages in the local time zone (local to the server).
Or am I seeing things wrongly here?
>
> BTW, Ilja, I drank to you on St. Patrick's day, for bringing back
> Thunderbird!
Well, ehm, thanks! :)

Ilja

RFC-3501 (IMAP4rev1) says...
2.3.3. Internal Date Message Attribute

The internal date and time of the message on the server. This
is not the date and time in the [RFC-2822] header, but rather a
date and time which reflects when the message was received. In
the case of messages delivered via [SMTP], this SHOULD be the
date and time of final delivery of the message as defined by
[SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
command, this SHOULD be the internal date and time of the source
message. In the case of messages delivered by the IMAP4rev1
APPEND command, this SHOULD be the date and time as specified in
the APPEND command description. All other cases are
implementation defined.

So I'm figuring that means local to the server. I'm wondering if the
mail client is supposed to be dealing with the offsets or what. Seems
if it was given in GMT, then the mail client should just compensate for
the time zone the person is in? What mail client are you using Blake?

Paul F. De La Cruz

On Fri, Mar 19, 2004 at 04:38:26PM +0100, Ilja Booij wrote:
> Blake Mitchell wrote:
>
> >So what would be involved in getting dbmail to do time zones? My mail
> >server is 3 time zones away, and all my received date are three hours off.
> I've been looking at this before, but I was a bit confused on how the
> IMAP server should implement it. As I understand it, the server should
> store the messages in the local time zone (local to the server).
> Or am I seeing things wrongly here?
> >
> >BTW, Ilja, I drank to you on St. Patrick's day, for bringing back
> >Thunderbird!
> Well, ehm, thanks! :)
>
> Ilja

Paul F. De La Cruz wrote:
> RFC-3501 (IMAP4rev1) says...
> 2.3.3. Internal Date Message Attribute
>
> The internal date and time of the message on the server. This
> is not the date and time in the [RFC-2822] header, but rather a
> date and time which reflects when the message was received. In
> the case of messages delivered via [SMTP], this SHOULD be the
> date and time of final delivery of the message as defined by
> [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
> command, this SHOULD be the internal date and time of the source
> message. In the case of messages delivered by the IMAP4rev1
> APPEND command, this SHOULD be the date and time as specified in
> the APPEND command description. All other cases are
> implementation defined.
>
> So I'm figuring that means local to the server. I'm wondering if the
> mail client is supposed to be dealing with the offsets or what. Seems
> if it was given in GMT, then the mail client should just compensate for
> the time zone the person is in? What mail client are you using Blake?

It looks likes the people who wrote the rfc assumed the server would
always be in the same time zone as the client...

We've had the same kind of trouble here, but even worse..: Apple Mail
(Mac OS X) would always display the Internal Data one hour in the future.
So a message arriving at 10:00AM would be displayed as having arrived
at 11:00AM. What seems to be the problem in this case is that Apple Mail
decided that mailservers should all have GMT internal time (we're at
GMT+1 here), and should compensate for that itself (without the
possibility of changing, unless you'd want to set the timezone zone
to GMT for your whole desktop...)

Anyway, switching to Mozilla Thunderbird fixed the problem :)

To conclude, I guess this is a pretty fundamental problem, which
cannot simply be dealt with by changing the timezone to GMT on your
server, because that will break some clients that are happily working
right now.

Ilja

Ilja Booij <ilja@ic-s.nl> said:

>
> Paul F. De La Cruz wrote:
> > RFC-3501 (IMAP4rev1) says...
> > 2.3.3. Internal Date Message Attribute
> >
> > The internal date and time of the message on the server. This
> > is not the date and time in the [RFC-2822] header, but rather a
> > date and time which reflects when the message was received. In
> > the case of messages delivered via [SMTP], this SHOULD be the
> > date and time of final delivery of the message as defined by
> > [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
> > command, this SHOULD be the internal date and time of the source
> > message. In the case of messages delivered by the IMAP4rev1
> > APPEND command, this SHOULD be the date and time as specified in
> > the APPEND command description. All other cases are
> > implementation defined.
> >
> > So I'm figuring that means local to the server. I'm wondering if the
> > mail client is supposed to be dealing with the offsets or what. Seems
> > if it was given in GMT, then the mail client should just compensate for
> > the time zone the person is in? What mail client are you using Blake?
>
> It looks likes the people who wrote the rfc assumed the server would
> always be in the same time zone as the client...
>
> We've had the same kind of trouble here, but even worse..: Apple Mail
> (Mac OS X) would always display the Internal Data one hour in the future.
> So a message arriving at 10:00AM would be displayed as having arrived
> at 11:00AM. What seems to be the problem in this case is that Apple Mail
> decided that mailservers should all have GMT internal time (we're at
> GMT+1 here), and should compensate for that itself (without the
> possibility of changing, unless you'd want to set the timezone zone
> to GMT for your whole desktop...)
>
> Anyway, switching to Mozilla Thunderbird fixed the problem :)
>
> To conclude, I guess this is a pretty fundamental problem, which
> cannot simply be dealt with by changing the timezone to GMT on your
> server, because that will break some clients that are happily working
> right now.
>
> Ilja

Is it possible that the times can all be marked as GMT, and that local server
time, when used to stamp received messages, also be converted to GMT? That
way, it becomes entirely encumbent upon the mail client to show the GMT date
in the user's local time. IIRC, the time format specified by RFC 2/822 has an
optional time zone field (haven't read it recently, though).

Aaron


--

reply below.. :D

On Sat, Mar 20, 2004 at 10:38:06AM -0000, Aaron Stone wrote:
> Ilja Booij <ilja@ic-s.nl> said:
>
> >
> > Paul F. De La Cruz wrote:
> > > RFC-3501 (IMAP4rev1) says...
> > > 2.3.3. Internal Date Message Attribute
> > >
> > > The internal date and time of the message on the server. This
> > > is not the date and time in the [RFC-2822] header, but rather a
> > > date and time which reflects when the message was received. In
> > > the case of messages delivered via [SMTP], this SHOULD be the
> > > date and time of final delivery of the message as defined by
> > > [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
> > > command, this SHOULD be the internal date and time of the source
> > > message. In the case of messages delivered by the IMAP4rev1
> > > APPEND command, this SHOULD be the date and time as specified in
> > > the APPEND command description. All other cases are
> > > implementation defined.
> > >
> > > So I'm figuring that means local to the server. I'm wondering if the
> > > mail client is supposed to be dealing with the offsets or what. Seems
> > > if it was given in GMT, then the mail client should just compensate for
> > > the time zone the person is in? What mail client are you using Blake?
> >
> > It looks likes the people who wrote the rfc assumed the server would
> > always be in the same time zone as the client...
> >
> > We've had the same kind of trouble here, but even worse..: Apple Mail
> > (Mac OS X) would always display the Internal Data one hour in the future.
> > So a message arriving at 10:00AM would be displayed as having arrived
> > at 11:00AM. What seems to be the problem in this case is that Apple Mail
> > decided that mailservers should all have GMT internal time (we're at
> > GMT+1 here), and should compensate for that itself (without the
> > possibility of changing, unless you'd want to set the timezone zone
> > to GMT for your whole desktop...)
> >
> > Anyway, switching to Mozilla Thunderbird fixed the problem :)
> >
> > To conclude, I guess this is a pretty fundamental problem, which
> > cannot simply be dealt with by changing the timezone to GMT on your
> > server, because that will break some clients that are happily working
> > right now.
> >
> > Ilja
>
> Is it possible that the times can all be marked as GMT, and that local server
> time, when used to stamp received messages, also be converted to GMT? That
> way, it becomes entirely encumbent upon the mail client to show the GMT date
> in the user's local time. IIRC, the time format specified by RFC 2/822 has an
> optional time zone field (haven't read it recently, though).
>
> Aaron

Yep, GMT is specified as +0000 hmm... interesting idea.

What's the proper netiquette for this? Zap the replies deeper than 2 or 3 '>'s
or just keep leaving notes at the top that the real message is at the end of
the yellow brick road? Perhaps we could all agree to reply on top... ;-)

Aaron


""Paul F. De La Cruz"" <polito@blackbeanie.net> said:

>
> reply below.. :D
>
> On Sat, Mar 20, 2004 at 10:38:06AM -0000, Aaron Stone wrote:
> > Ilja Booij <ilja@ic-s.nl> said:
> >
> > >
> > > Paul F. De La Cruz wrote:
> > > > RFC-3501 (IMAP4rev1) says...
> > > > 2.3.3. Internal Date Message Attribute
> > > >
> > > > The internal date and time of the message on the server. This
> > > > is not the date and time in the [RFC-2822] header, but rather a
> > > > date and time which reflects when the message was received. In
> > > > the case of messages delivered via [SMTP], this SHOULD be the
> > > > date and time of final delivery of the message as defined by
> > > > [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
> > > > command, this SHOULD be the internal date and time of the source
> > > > message. In the case of messages delivered by the IMAP4rev1
> > > > APPEND command, this SHOULD be the date and time as specified in
> > > > the APPEND command description. All other cases are
> > > > implementation defined.
> > > >
> > > > So I'm figuring that means local to the server. I'm wondering if the
> > > > mail client is supposed to be dealing with the offsets or what. Seems
> > > > if it was given in GMT, then the mail client should just compensate for
> > > > the time zone the person is in? What mail client are you using Blake?
> > >
> > > It looks likes the people who wrote the rfc assumed the server would
> > > always be in the same time zone as the client...
> > >
> > > We've had the same kind of trouble here, but even worse..: Apple Mail
> > > (Mac OS X) would always display the Internal Data one hour in the future.
> > > So a message arriving at 10:00AM would be displayed as having arrived
> > > at 11:00AM. What seems to be the problem in this case is that Apple Mail
> > > decided that mailservers should all have GMT internal time (we're at
> > > GMT+1 here), and should compensate for that itself (without the
> > > possibility of changing, unless you'd want to set the timezone zone
> > > to GMT for your whole desktop...)
> > >
> > > Anyway, switching to Mozilla Thunderbird fixed the problem :)
> > >
> > > To conclude, I guess this is a pretty fundamental problem, which
> > > cannot simply be dealt with by changing the timezone to GMT on your
> > > server, because that will break some clients that are happily working
> > > right now.
> > >
> > > Ilja
> >
> > Is it possible that the times can all be marked as GMT, and that local server
> > time, when used to stamp received messages, also be converted to GMT? That
> > way, it becomes entirely encumbent upon the mail client to show the GMT date
> > in the user's local time. IIRC, the time format specified by RFC 2/822 has an
> > optional time zone field (haven't read it recently, though).
> >
> > Aaron
>
> Yep, GMT is specified as +0000 hmm... interesting idea.
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>



--

That might be a good idea... I'd generally been taking the course of
action the last person took. :D So if the last person answered at the bottom,
then I answered at the bottom. If they answered inline, then I might answer
inline. If they answer at the top, I'd answer at the top. I'm not sure if
there is a proper netiquette for this really. Aside from I'd try to cut out
too many signature lines to keep the messages shorter :D

Paul F. De La Cruz

On Sat, Mar 20, 2004 at 06:01:26PM -0000, Aaron Stone wrote:
> What's the proper netiquette for this? Zap the replies deeper than 2 or 3 '>'s
> or just keep leaving notes at the top that the real message is at the end of
> the yellow brick road? Perhaps we could all agree to reply on top... ;-)
>
>
> ""Paul F. De La Cruz"" <polito@blackbeanie.net> said:
>
> >
> > reply below.. :D

On Sat, 2004-03-20 at 13:01, Aaron Stone wrote:
> What's the proper netiquette for this? Zap the replies deeper than 2 or 3 '>'s
> or just keep leaving notes at the top that the real message is at the end of
> the yellow brick road? Perhaps we could all agree to reply on top... ;-)

I prefer to reply below the text (as evidenced by this message) since it
flows more naturally, however I think the proper netiquette is to only
include relevant text. If people need to see the earlier history of a
thread, they can look in the earlier emails.

Matthew