|
Re: Good & Easy Date Module?
by Coyote (Deacon) on Feb 21, 2001 at 22:00 UTC
|
Date::Manip does everything and is pure perl so it runs everywhere. The downside is that it is slow and fairly complicated. Having said that, I've used it for a number of projects and its worth the time I spent learning it.
Date::Calc is written in C and is much faster than Date::Manip. If it does what you want it to do, I would go with it (I didn't because it is/was unavailable for MacOS).
I would avoid writing your own here. Dealing with dates is one of those issues that is extremely complicated and exception filled. You are probably better off learning a well tested, but complicated module than reinventing one yourself. I put rewritting date routines along side trying to reinvent CGI.pm or HTML::Parser. Don't do it unless you have a very good reason.
----
Coyote | [reply] |
|
|
Danger Will Robinson!
I used Date::Calc a while back when grovelling through
web logs. In essence, I wanted to split out information
week by week. I used Time::Local to convert the the web
timestamp into epoch time. I then had to walk backwards,
firstly to get back to Sunday 0:00, and from there walk
backwards week by week.
The details are a little hazy, and in any event the
project got wiped out by a catastrophic hard disk failure
before I backed things up.
The thing is, I was using Date::Calc::Add_Delta_DHMS,
walking back week by week, and started getting weird
off-by-one errors. In the end I got around the problem by
just dealing with epoch time and subtracting 86400*7,
and the numbers came out fine.
I did mean to prepare a test to prove or disprove the
bug, but ran out of tuits. All that to say watch out if
you use the Add_Delta_* functions.
grinder
| [reply] |
|
|
Lemme bet the rent on this one...
You were using a time between 12 midnight and 1am as your base time, and you crossed the spring daylight savings time boundary when a day had only 23 hours.
Then you'll be off a day. If this is the case, your epoch +/- 86400*7 solution will also fail, and you've only been lucky not to hit the same case.
So the problem was not Date::Calc, but in a misunderstanding that there's not always 24 hours in a day.
-- Randal L. Schwartz, Perl hacker
| [reply] |
|
|
|
|
Re: Good & Easy Date Module?
by TheoPetersen (Priest) on Feb 21, 2001 at 22:05 UTC
|
Date::Manip is your friend. There's a lot of documentation,
yes, but that's a good thing. There are examples that match some
of the things you are looking for; here's one I filched from the pod:
perl -MDate::Manip -e '$_ = &UnixDate("Friday in 2 weeks", "%m/%d/%Y")
+; print "$_\n";
ZZamboni's review offers more examples. Read it over,
then ask specific questions if you can't figure out how to do what you want. | [reply]
[d/l] |
Re: Good & Easy Date Module?
by arturo (Vicar) on Feb 21, 2001 at 22:13 UTC
|
Inflexible example non-module solution, which I'm not really recommending: second Thursday every month ... Must be (a) Thursday, (b) at least the 8th, and (c) no later than the 15th
(is that even right? I think so, but you use a module to let someone else worry about such things)
sub second_thursday {
my ($dow, $dom) = (split " ", scalar localtime)[0,2];
($dow eq "Thu" && $dom > 7 && $dom < 16 )
? 1 : 0;
}
( note: altered from its original form, to be plus élégant =) )
And you'll have to do something like that for the others, too. scalar localtime produces some pretty useful stuff, but there are all sorts of tricks n' traps (like, I'm not sure whether splitting on a single space works when the day of the month is < 10 ...)
Philosophy can be made out of anything. Or less -- Jerry A. Fodor | [reply]
[d/l]
[select] |
Re: Good & Easy Date Module?
by Desdinova (Friar) on Feb 21, 2001 at 22:17 UTC
|
I have done a little a work with Time::ParseDate I have only done some basic conversions with it but it has worked well when i needed it | [reply] |
Re: Date::Calc vs Date::Manip
by markjugg (Curate) on Feb 22, 2001 at 03:35 UTC
|
I've worked with both Date::Manip and Date::Calc and would describe the difference like this: Date::Calc is great for working with structured dates. So if you are getting data from web forms where you can control the input format, sticking it in database, and printing it back out, then Date::Calc is a great choice.
Date::Manip has the strength of being able to parse all manner of english descriptions of dates and "date math" into a real date format and spit back out lots of ways. The project we used was on was noticeably slower as a CGI script, which was one of the reasons we explored Date::Calc.
I use Date::Calc as my first choice date parsing module and I'm very happy with it.
-mark
| [reply] |
Re: Good & Easy Date Module?
by Anonymous Monk on Feb 21, 2001 at 23:33 UTC
|
I like Date::Calc, personally. I wound up writing a wrapper object for it that would split dates into separate $yy, $mm, $dd variables, call into Date::Calc, then reassemble the results into what I wanted.
Whichever solution you go with, I'd suggest writing wrappers around the subset you need if you only need a few functions out of 50, make the API what you want it to be, and use that.
--wesley | [reply] |
Re: Good & Easy Date Module?
by McD (Chaplain) on Feb 22, 2001 at 03:59 UTC
|
It may not fit your problem set, or you might have to rethink your approach in order to use it,
but consider trying Schedule::Cron for this one.
Peace,
-McD
| [reply] |
Re: Good & Easy Date Module?
by BlueLines (Hermit) on Feb 22, 2001 at 05:01 UTC
|
I agree with McD. cron(8) or at(1) is what you want here. IMHO you're reinventing the wheel. Even though it's possible to do in perl, I think this is a case where it's not really worth it.
BlueLines
Disclaimer: This post may contain inaccurate information, be habit forming, cause atomic warfare between peaceful countries, speed up male pattern baldness, interfere with your cable reception, exile you from certain third world countries, ruin your marriage, and generally spoil your day. No batteries included, no strings attached, your mileage may vary. | [reply]
[d/l]
[select] |