Skip to Content.
Sympa Menu

devel - Re: [sympa-developpers] CPAN alternatives for time-related functions

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: IKEDA Soji <address@concealed>
  • To: address@concealed
  • Subject: Re: [sympa-developpers] CPAN alternatives for time-related functions
  • Date: Sun, 30 Mar 2014 17:42:14 +0900

Hi,

I checked these CPAN modules to parse Date: header field.

Date::Manip 6.25
Date::Parse 1.20
DateTime::Format::HTTP 0.40
DateTime::Format::Mail 0.3001 (strict mode)
DateTime::Format::Mail 0.3001 (loose mode)

Result is attached.

- Date::Manip::Date::parse() can't resognize numeric timezone,
cannot handle 2-digit year in 21th century and cannot handle
leap second.

- Date::Parse::str2time() generates spurious result on some
inputs (see [2], [8], [13] in result), and cannot handle leap
second.

- DateTime::Format::HTTP->parse_datetime() cannot parse RFC 822
format.

- DateTime::Format::Mail::parse_datetime() is too strict without
loose mode.

- None of them can handle obsoleted format (RFC 733 or earlier).

In conclusion, I suggest DateTime::Format::Mail with loose mode.

Regards,

--- Soji

On Tue, 25 Mar 2014 12:40:26 +0900
IKEDA Soji <address@concealed> wrote:

> Hi,
>
> On Mon, 24 Mar 2014 15:30:57 +0100
> Guillaume Rousse <address@concealed> wrote:
>
> > The Sympa::Tools::Time module contains a few time-related functions,
> > mostly related to conversion between string and timestamps formats:
> > epoch2yyyymmjj_hhmms()
> > adate()
> > get_midnight_time()
> > epoch_conv()
> > date_conv()
> > duration_conv()
>
> I overlookded these functions.
>
> epoch2yyyymmjj_hhmms() is used only once;
> adate() is never used;
> get_midnight_time() is used only once.
>
> Former two may be replaced with strftime() (although locale should
> be considered).
>
> > parse_date()
>
> Date::Parse::str2time() may be an alternative to
> time_utils::parse_date() if it is targetted to Date: header fields.
> And anyway nothing is better than the module recently maintained.
> I don't stick to this module.
>
>
> > Those 300 lines of code would easily be replaced by some perl module
> > available from CPAN. Here is a list of potential alternatives:
> >
> > 1) Date::Parse: no dependencies, pure perl, but limited to date string
> > conversions (it would not replace duration_conv(), for instance).
> >
> > 2) Date::Manip: few dependencies, pure perl, no idea about the exact
> > coverage
> >
> > 3) DateTime framework (DateTime, DateTime::Format::Mail, etc...):
> > multiple dependencies, native code, but covers practically everything.
> >
> > They could be potentially others, but I limited myself to the one known
> > to be actively maintained nowadays.
> >
> > That's basically a choice between a lightweight-but-limited vs
> > heavywheight-but-complete external dependency. I'd personaly go for
> > DateTime framework, which is basically in line with the "let's get rid
> > of old environement constraints", but that's a merely a project
> > management decision.
>
> Regards,
>
> --- Soji
>
>
> --
> 株式会社 コンバージョン セキュリティ&OSSソリューション部 池田荘児
> 〒231-0004 神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
> e-mail address@concealed TEL 045-640-3550
> http://www.conversion.co.jp/


--
株式会社 コンバージョン セキュリティ&OSSソリューション部 池田荘児
〒231-0004 神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed TEL 045-640-3550
http://www.conversion.co.jp/

Input Expected result D::M::D D::P
DT::F::H DT::F::M DT::F::M(loose)
24 JUL 1973 1527-PDT 1973-07-24T22:27:00Z [1] [1]
[1] [1] [1] RFC 561
26 August 1976 1429-EDT 1976-08-26T18:29:00Z [1] [1]
[1] [1] [1] RFC 724
Wednesday, 8/31/76 1251-Z 1976-08-31T12:51:00Z [1] [1]
[1] [1] [1] RFC 724 (not recommended)
27 Aug 1976 0932-PDT 1976-08-27T16:32:00Z [1] [1]
[1] [1] [1] RFC 733
26 Aug 76 14:29:01 EDT 1976-08-26T18:29:01Z OK OK
[1] OK OK RFC 822
Fri, 15 Mar 2002 16:53 +0915 2002-03-15T07:38:00Z [1] OK
OK [1] OK RFC 1123
1 Dec 1993 15:40:28 -0000 1993-12-01T15:40:28Z OK OK
OK OK OK other variants
15 Dec 1993 18:00:37 GMT 1993-12-15T18:00:37Z OK OK
OK OK OK
4 Dec 93 23:53:10 GMT 1993-12-04T23:53:10Z OK OK
OK OK OK
Tue, 14 Dec 1993 21:29:02 GMT 1993-12-14T21:29:02Z OK OK
OK OK OK
Wed, 8 Dec 93 07:51:39 GMT 1993-12-08T07:51:39Z OK OK
OK OK OK
Mon, 06 Dec 93 22:05:22 +1000 (AEST) 1993-12-06T12:05:22Z [1] OK
OK [1] OK
Monday 13 April, 1992 09:30:00 PDT 1992-04-13T16:30:00Z OK OK
[1] [1] [1] nonstandard
Monday, March 3, 12:59:00 CDT error OK [2]
OK OK OK incorrect
Monday May 24 23:01:34.34 CDT 1993 error [3] [3]
OK OK OK incorrect
Thu, 2 Dec 1993 12:53:49 error [4] [4]
[5] [5] [5] incorrect
Wed, 15 Dec 1993 13:36:54 UNDEFINED error OK OK
OK OK [6] incorrect
Sat, 1 Jan 00 00:00:00 +0900 1999-12-31T15:00:00Z OK OK
OK OK OK Y2k workaround
Tue, 19 Jan 38 12:14:08 +0900 (KST) 2038-01-19T03:14:08Z [1] OK
OK [1] OK
Fri, 31 Dec 49 14:59:59 +0000 2049-12-31T14:59:59Z [1] OK
OK OK OK
Sun, 1 Jan 50 00:00:00 +0000 1950-01-01T00:00:00Z OK [7]
[7] OK OK
Tue, 19 Jan 138 12:14:08 +0900 (KST) 2038-01-19T03:14:08Z [1] [8]
[9] [1] [1]
Sun, 1 Jul 2012 08:59:60 +0900 2012-07-01T00:00:00Z [1] [1]
OK OK OK leap second
Thu, 1 Jan 1970 03:00:00 +0300 1970-01-01T00:00:00Z OK OK
OK OK OK UNIX epoch
Tue, 29 Oct 1969 12:00:00 -0800 (PST) 1969-10-29T20:00:00Z [1] OK
OK [1] OK pre-epoch
Sat, 31 Dec 1949 15:00:00 +0000 1949-12-31T15:00:00Z OK [10]
OK OK OK
Thu, 1 Jan 1900 00:00:00 GMT 1900-01-01T00:00:00Z [1] OK
OK OK OK previous centuries
Thu, 14 Sep 1752 09:00:00 GMT 1752-09-13T23:41:01Z [11] [11]
[11] [11] [11]
Wed, 1 Jan 1000 09:00:00 GMT 999-12-31T23:41:01Z [12] [12]
[12] [12] [12]
Tue, 31 Dec 999 09:00:00 GMT error OK [13]
[14] OK OK

[1] error
[2] 2014-03-03T17:59:00Z
[3] 1993-05-25T04:01:34Z
[4] 1993-12-02T03:53:49Z
[5] 1993-12-02T12:53:49Z
[6] 1993-12-15T13:36:54Z
[7] 2050-01-01T00:00:00Z
[8] 2014-01-19T03:14:08Z
[9] 138-01-19T03:14:08Z
[10] 2049-12-31T15:00:00Z
[11] 1752-09-14T09:00:00Z
[12] 1000-01-01T09:00:00Z
[13] 2013-12-30T22:21:00Z
[14] 999-12-31T09:00:00Z

Attachment: datefmt.pl
Description: Perl program




Archive powered by MHonArc 2.6.19+.

Top of Page