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.
Re:Date::ICal + Time::Piece?
IlyaM on 2003-01-03T17:08:46
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?
Re:Date::ICal + Time::Piece?
Matts on 2003-01-03T17:53:19
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.Re:Date::ICal + Time::Piece?
autarch on 2003-01-03T18:08:07
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.Re:Date::ICal + Time::Piece?
bart on 2003-01-03T20:16:53
Most of all, I want such a module to be lightweight.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.Isn't parsing dates in wierd formats a bit overrated though?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.
I like Time::Local, by which you can turn a normal date into a seconds-since-epoch value. Minimal, but it does the job. The main culprit, IMO, is in the limited range on the dates.
Re:Date::ICal + Time::Piece?
autarch on 2003-01-03T20:48:56
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, this is what a module _suite_ is for. You load the parts you need. Forcing users to implement their own parsing routines, especially when some rather clever ones already exist in module like Date::Manip, is just ridiculous.Re:Date::ICal + Time::Piece?
bart on 2003-01-03T21:04:19
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!Forcing users to implement their own parsing routines, especially when some rather clever ones already exist in module like Date::Manip, is just ridiculous.Re:Date::ICal + Time::Piece?
autarch on 2003-01-03T21:23:19
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.Re:Date::ICal + Time::Piece?
bart on 2003-01-15T12:50:15
We might be talking about different things here. Take a look at a page like this, 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. 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.
I've never had the need to parse a string like "Tuesday after the next", and I doubt I ever will.
Re:Date::ICal + Time::Piece?
autarch on 2003-01-15T18:21:24
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 need to parse a string like "Tuesday after the next", and I doubt I ever will.
Then you'll never have to load the extended parsing code. What's your point? Just cause you don't use it doesn't mean nobody else does.
Re:Date::ICal + Time::Piece?
autarch on 2003-01-03T18:07:19
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::Manip wins here.
-- Actually understands real time zones _and_ DST on a per-region basis. GMT offsets just don't cut it, because these change (or don't) based on whether a region follows DST. Instead of a time zone offset, a date object should have a time zone region, which would know about this sort of stuff. Check out this page for more details. All the data necessary to do this exists and is a standard UNIX thing (the tz or zoneinfo database). I'm not sure about other OS's.
It might be best to simply turn this into a Perl module and distribute it.
- Date deltas
-- Date delta objects and the associated math. I think Date::ICal::Duration does some of this but I don't think you can do date math with 2 duration objects (which should be possible).
-- Should handle business versus normal days.
-- Should be able to plug in a holiday calendar and do things like ask "5 business days from now" and have it respect calendar.
- Recurring date objects
-- This should integrate well with the previously mentioned objects. For example, given a recurring date object, I should be able to get the next date object, previous, iterate through them, etc.
Additionally, I should be able to ask it "what's the delta to the next occurrence", etc.
-- This needs to handle both finite and infinite recurring dates.
-- Recursive date parsing. Date::Manip does.
- Timespan objects
-- Again, this needs to integrate with the other objects well. I should be able to ask whether a given datetime is inside the timespan, get start and end datetimes, get a date delta for the time spanned.
- Recurring timespan objects
-- "Every Tuesday from 13:30 - 15:00 until March 15" should be representable. Again, integration with the other objects is the real key, to my mind.
-- Parsing of this would be cool as well;)
A lot of this stuff actually already exists.
Date::Calc handles business days and includes the Date::Calendar module, which can be used for holidays.
Date::Handler's "intuitive date calculations" are worth having as well.
Date::Set handles recurring dates, and I think it handles timespans as well. It's API is somewhat confusing. Also see Date::Interval, another module with a weird API (and not enough docs) but some interesting functionality. I'm not sure if its a subset of Date::Set or not, but if it isn't it's functionality would be nice to have.
Date::Manip handles lots of complex date and recurring date parsing.
The only thing that I don't think exists is the time zone functionality I mentioned, although it looks like Date::Handler's use of the POSIX functions for time zones may actually do the right thing.
And of course this whole mess needs to be properly localizable;) Re:Date::ICal + Time::Piece?
Theory on 2003-01-03T18:37:24
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
Re:Date::ICal + Time::Piece?
tex on 2003-01-09T21:29:14
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/Re:Date::ICal + Time::Piece?
autarch on 2003-01-09T23:34:53
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.Re:Date::ICal + Time::Piece?
jordan on 2003-01-03T18:53:45
- And, don't forget the very important adding two dates that a Saint over at Perlmonks seems to be a FAQ.
Re:Date::ICal + Time::Piece?
jesse on 2003-01-04T09:12:01
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.Re:Date::ICal + Time::Piece?
nicholas on 2003-01-10T12:05:25
-- 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?
Re:Date::ICal + Time::Piece?
autarch on 2003-01-10T17:53:42
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.
