Skip Menu |

This queue is for tickets about the Mail-IMAPClient CPAN distribution.

Report information
The Basics
Id: 31971
Status: resolved
Priority: 0/
Queue: Mail-IMAPClient

People
Owner: Nobody in particular
Requestors: dagolden [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 3.02
Fixed in: (no value)



Subject: Rfc2060_datetime() needs to include a timezone
The formal grammar specification for date-time in RFC3501 (updated from 2060) requires a time zone: date-time = DQUOTE date-day-fixed "-" date-month "-" date-year SP time SP zone DQUOTE zone = ("+" / "-") 4DIGIT ; Signed four-digit value of hhmm representing ; hours and minutes east of Greenwich (that is, ; the amount that the given time differs from ; Universal Time). Subtracting the timezone ; from the given time will give the UT form. ; The Universal Time zone is "+0000". c.f. http://www.isi.edu/in-notes/rfc3501.txt This is important for APPEND commands. Some IMAP servers (e.g. Gmail) reject APPEND with an invalid timestamp. I suggest a syntax like this: Rfc2060_datetime( $epoch_secs, $zone ) $zone should be in the same format as the zone grammer. If invalid or not supplied, just default to "+0000". As a side note, there is no check that the first argument is defined. If it isn't defined, you should probably just default to 0.
Subject: Re: [rt.cpan.org #31971] Rfc2060_datetime() needs to include a timezone
Date: Sat, 29 Dec 2007 22:05:13 +0100
To: David Golden via RT <bug-Mail-IMAPClient [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* David Golden via RT (bug-Mail-IMAPClient@rt.cpan.org) [071228 18:49]: Show quoted text
> Fri Dec 28 13:49:26 2007: Request 31971 was acted upon. > Transaction: Ticket created by DAGOLDEN > Queue: Mail-IMAPClient > Subject: Rfc2060_datetime() needs to include a timezone > > The formal grammar specification for date-time in RFC3501 (updated from > 2060) requires a time zone: > > date-time = DQUOTE date-day-fixed "-" date-month "-" date-year > SP time SP zone DQUOTE
Not only 3501 requires it, but it is also in 2060. It will be fixed. Show quoted text
> I suggest a syntax like this: > Rfc2060_datetime( $epoch_secs, $zone ) > > $zone should be in the same format as the zone grammer. If invalid or > not supplied, just default to "+0000". > > As a side note, there is no check that the first argument is defined. > If it isn't defined, you should probably just default to 0.
This is less easy than it looks. Do we specify the $zone in seconds? Or as +0315? And how to correct the $epoch_secs? For now, I think adding a +0000 to the output is sufficient. OK? -- Thanks MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Subject: Re: [rt.cpan.org #31971] Rfc2060_datetime() needs to include a timezone
Date: Sat, 29 Dec 2007 16:44:41 -0500
To: bug-Mail-IMAPClient [...] rt.cpan.org
From: "David Golden" <dagolden [...] cpan.org>
On Dec 29, 2007 4:05 PM, Mark Overmeer via RT <bug-Mail-IMAPClient@rt.cpan.org> wrote: Show quoted text
> This is less easy than it looks. Do we specify the $zone in seconds? > Or as +0315? And how to correct the $epoch_secs? > > For now, I think adding a +0000 to the output is sufficient. OK?
I think that's sufficient for a quick fix. However, I would suggest something like this: my ($class, $stamp, $zone) = @_; $stamp = 0 unless defined $stamp && $stamp > 0; $zone = "+0000" unless defined $zone && $zone =~ m{^(+|-)\d{4}$}; In my opinion, you can leave it to the user to provide a valid zone or just default them to +0000. It would be slightly nicer to warn if overriding invalid stamps or zones, but I think just having some sane output is the important thing. David
Subject: Re: [rt.cpan.org #31971] Rfc2060_datetime() needs to include a timezone
Date: Sat, 29 Dec 2007 23:23:32 +0100
To: David Golden via RT <bug-Mail-IMAPClient [...] rt.cpan.org>
From: Mark Overmeer <mark [...] overmeer.net>
* David Golden via RT (bug-Mail-IMAPClient@rt.cpan.org) [071229 21:45]: Show quoted text
> However, I would suggest something like this: > > my ($class, $stamp, $zone) = @_; > $stamp = 0 unless defined $stamp && $stamp > 0;
$stamp < 0 is valid (on HP for instance, it is before 1970) Show quoted text
> $zone = "+0000" unless defined $zone && $zone =~ m{^(+|-)\d{4}$}; > > In my opinion, you can leave it to the user to provide a valid zone or > just default them to +0000. It would be slightly nicer to warn if > overriding invalid stamps or zones, but I think just having some sane > output is the important thing.
The problem is how to make this a failsafe user interface. Is the stamp since epoc, then the gmtime must be passed with a value which is zone_to_seconds($zone) earlier than the passed stamp. Or should the user pass a corrected value? Or is the zone specified in seconds? Or can we get the zone automatically, as best default? These doubt keep me from implementing it. The implementation itself is extremely easy. -- Regards, MarkOv ------------------------------------------------------------------------ Mark Overmeer MSc MARKOV Solutions Mark@Overmeer.net solutions@overmeer.net http://Mark.Overmeer.net http://solutions.overmeer.net
Subject: Re: [rt.cpan.org #31971] Rfc2060_datetime() needs to include a timezone
Date: Sun, 30 Dec 2007 11:19:55 -0500
To: bug-Mail-IMAPClient [...] rt.cpan.org
From: "David Golden" <dagolden [...] cpan.org>
On Dec 29, 2007 5:23 PM, Mark Overmeer via RT <bug-Mail-IMAPClient@rt.cpan.org> wrote: Show quoted text
> The problem is how to make this a failsafe user interface. Is the > stamp since epoc, then the gmtime must be passed with a value which > is zone_to_seconds($zone) earlier than the passed stamp. Or should > the user pass a corrected value? Or is the zone specified in seconds? > Or can we get the zone automatically, as best default?
Oh, I see. I'd leave it to the user. Let $stamp be localtime seconds and $zone be an offset to UTC. Then Rfc_2060( time ) produces a UTC time. If I really want a localtime, I have to do the math (with whatever date/time modules I prefer). E.g.: Rfc_2600( time - 5 * 3600, "-0500" ) I'd suggest zone be +|-HHMM rather than seconds just because that's closer to the 2060/2822 spec. David
ok, implemented.