Re: INTERNALDATE one hour in future for sent message

2006-07-12 Thread Jim Brett
o, US/Eastern is same as setting to EST5EDT (to test this I changed setting TZ in TIMEZONE file to EST5EDT and rebooted. Same behavior as if TZ set to US/Eastern). It's really just asking the operating system for "the current time", so the OS is not using GMT. IS there an

Re: INTERNALDATE one hour in future for sent message

2006-06-28 Thread Phil Pennock
On 2006-06-28 at 16:43 -0400, Jim Brett wrote: > Thanks, your response is greatly appreciated. Here's OS info: > > # uname -a > SunOS machine.company.com 5.8 Generic_117350-13 sun4u sparc > SUNW,Sun-Fire-V240 Edit /etc/TIMEZONE, zone information available in /usr/share/lib/zoneinfo/ $ man -s 4

Re: INTERNALDATE one hour in future for sent message

2006-06-28 Thread Jim Brett
Thanks, your response is greatly appreciated. Here's OS info: # uname -a SunOS machine.company.com 5.8 Generic_117350-13 sun4u sparc SUNW,Sun-Fire-V240 Phil wrote: On 2006-06-28 at 10:21 -0400, Jim wrote: INTERNALDATE (hence received date?) one hour in future for sent me

Re: INTERNALDATE one hour in future for sent message

2006-06-28 Thread Phil Pennock
On 2006-06-28 at 10:21 -0400, Jim Brett wrote: > INTERNALDATE (hence received date?) one hour in future for sent > message. Unix systems should be run in GMT/UTC (almost the same thing; GMT is _not_ "British time"). You then use $TZ in the environment, or some OS-dependen

INTERNALDATE one hour in future for sent message

2006-06-28 Thread Jim Brett
INTERNALDATE (hence received date?) one hour in future for sent message. I realize that a received date on a message in sent folder doesn't really have meaning but, if a user moves from sent to inbox (or trash), then clients (including outlook and outlook express) sort by received date

Re: [PATCH] Use INTERNALDATE for ipurge (was: ipurge to use -d as receive date and not sent date)

2003-11-05 Thread Carsten Hoeger
On Tue, Oct 14, Henrique de Moraes Holschuh wrote: > Please try the attached patch. > > It switches default behaviour to least-surprise (INTERNALDATE), adds > -X to get the old behaviour, and enhances ipurge by adding -i to invert > match logic. I am a little bit late on this to

[PATCH] Use INTERNALDATE for ipurge (was: ipurge to use -d as receive date and not sent date)

2003-10-14 Thread Henrique de Moraes Holschuh
Please try the attached patch. It switches default behaviour to least-surprise (INTERNALDATE), adds -X to get the old behaviour, and enhances ipurge by adding -i to invert match logic. On Tue, 14 Oct 2003, Carsten Hoeger wrote: > On Tue, Oct 14, Rob Siemborski wrote: > > If a patch was

Re: internaldate

2003-04-04 Thread Alexander Brill
On Wed, 2003-04-02 at 16:55, Ken Murchison wrote: > Alexander Brill wrote: > > > > I am trying to set the internaldate for a message, but it doesn't store > > properly. > > > > This is what I try (using python) > > imap.store(1,"+FLAGS","

Re: internaldate

2003-04-02 Thread Ken Murchison
Alexander Brill wrote: > > I am trying to set the internaldate for a message, but it doesn't store > properly. > > This is what I try (using python) > imap.store(1,"+FLAGS","INTERNALDATE 22-Mar-2003 02:10:31 +0100") > > ('OK', [&

internaldate

2003-04-02 Thread Alexander Brill
I am trying to set the internaldate for a message, but it doesn't store properly. This is what I try (using python) imap.store(1,"+FLAGS","INTERNALDATE 22-Mar-2003 02:10:31 +0100") > ('OK', ['1 (FLAGS (INTERNALDATE 22-Mar-2003 02:10:31 +0100))'])