Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

autarch (914)

autarch
  (email not shown publicly)
http://www.vegguide.org/

Journal of autarch (914)

Friday January 03, 2003
11:30 AM

Perl dates and times

[ #9746 ]

There are so many date and time modules on CPAN, it's scary. It's similar to the situation with template modules and DBI wrappers. I've been thinking of trying to write "the one true date/time" module, primarily by ripping apart the other modules and producing something that did all the useful things they do, but with a consistent API.

It'd be a cool thing to have, but I'm tired right now. Maybe later in the year.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Perl dates and times 18 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'm thinking of re-building Time::Piece on top of Date::ICal, which has very cool support for adding and subtracting times and doing periodic events.

    Is there anything that a combination of those two would miss?
    • Is there anything that a combination of those two would miss?

      Power of Date::Manip and/or Date::Parse when it comes to parsing dates?

      --

      Ilya Martynov (http://martynov.org/ [martynov.org])

      • Isn't parsing dates in wierd formats a bit overrated though?

        What I mean is, isn't it better to specify X different acceptable formats than just hope the magic internals of a library will make it all work for you? Time::Piece lets you do that with it's strptime support.
        • I think having something like Date::Manip's parsing loadable as a separate module is definitely worthwhile. It shouldn't be part of the core a generic datetime module though.
        • Most of all, I want such a module to be lightweight.

          Isn't parsing dates in wierd formats a bit overrated though?

          I think so. My date parsing mostly involves dates in Dutch (and English). Ideally, the module should be able to parse that... but on the other hand, I don't want it to be so bulky that it also contains the code to parse dates in Mongolian.

          So my idea would be: let the user do the parsing with, say, a regex, and pass the data to the built-in function, together with an array of the month names

          • I think so. My date parsing mostly involves dates in Dutch (and English). Ideally, the module should be able to parse that... but on the other hand, I don't want it to be so bulky that it also contains the code to parse dates in Mongolian.

            So my idea would be: let the user do the parsing with, say, a regex, and pass the data to the built-in function, together with an array of the month names — or day names, depending on what you're trying to parse. And let the function figure it out from there.

            Uh,
            • Forcing users to implement their own parsing routines, especially when some rather clever ones already exist in module like Date::Manip, is just ridiculous.
              It depends. Chances are that none of the numerous existing implemented methods are quite right for your current project. And parsing a date from a string is not that hard. After all, this is Perl!
              • You need to take a look at the code in Date::Manip and then reconsider your comment. Parsing things like "the Tuesday after next" is _really_ hard, and re-implementing it is ridiculous.

                If all you're after is basic parsing then the Date::Parse module does that just fine in a couple hundred lines of code. Re-implementing either of those as a one-off would be foolish. Mandating that people re-implement them is ridiculous.
                • We might be talking about different things here. Take a look at a page like this [bbc.co.uk], a HTML page with a listing of today's television programmes. Once retrieved, I want to verify I have a page of the correct date you're never sure with possibly stale caches. Will your modules do that? Will it be able to extract the proper date string? I doubt it. (Note that there is more than one date on that page.) A regex, combined with a HTML parsing module, will:

                  /\w+day (\d+)\S* (\w+)/

                  That was the hard part. No


                  • That was the hard part. Now we have all the elements we need to interpret this date. Do I need to use a, possibly large, date module? Hell, no, as a simple hash lookup is all we need to turn the month name into a month number. I'm not talking about hundreds of lines of code, obviously.

                    Ok, then don't use it for this particular purpose. This module will be more useful for people who have to deal with date calculations than those who just need to parse really simple date formats.


                    I've never had the

    • Here's a quick summary of what I think the "uber-date/time" module would look like:

      - Date objects

      -- Simple OO interface for doing basic things. I like how Time::Piece does this.

      -- Date math via overloading. Time::Piece and Time::Seconds are not bad. Looks like Date::ICal has support for more complex date math.

      -- Works outside of epoch times. Date::ICal does this.

      -- Simple date parsing. Time::Piece->strptime plus the functionality of Date::Parse would be good.

      -- Complex date parsing. Date::Man

      • I think that this is a great idea, overall. My only requests would be that a) the different functionalities be in related modules, so that you only load what you need; and b) that it be fast -- very fast.

        Perhaps you should start a project or at least a discussion list of some kind so that interested parties can contribute and collaborate on a design spec? I'd sign up. Hopefully Matts would have time to participate, too!

        --David

        • This was already tried a while ago and it didn't go over well.

          Review the archive of datetime@perl.org:
          http://archive.develooper.com/datetime@perl.org/ [develooper.com]

          --

          -- tex

          • I actually have a different approach to this than Rich. I personally don't give a flying *beep* what other module authors think. If they don't want to cooperate, fine. They released their code under a license which lets me include it in something else, and I plan to do that wherever necessary.

            I think Rich was just too damn nice about the whole thing. Anyway, I just posted a new proposal to that mailing list, so anyone interested should sign up.
        • And, don't forget the very important adding two dates [perlmonks.org] that a Saint over at Perlmonks seems to be a FAQ.
      • So, the reefknot acutally started in on all the timezones in native perl. check out Date::ICal::Timezone from reefknot CVS. Basically, I lamed on actually making things work right with Date::Set. The bits are all there, including a whole olson timezone database as perl datastructures. ping me if you want to talk about where I went wrong or start hacking on it. Date::ICal (and subclasses) and Date::Set are, IMO, the best building blocks we have for all our date math needs.
      • -- Should handle business versus normal days.

        Do the days that are treated as business days vary between countries. Here in the UK Monday to Friday are business days (and have been for the past century or two), and I assume that this is true in most or all (notionally) Christian countries. But do countries where other religions are dominant observe different business days?

        • But do countries where other religions are dominant observe different business days?

          Uh, I'll give you one guess ;) The solution is to make the determination of what constitutes a business day pluggable via different calendar objects or something like that.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.