getting date

I want to get the date after the no. of days passed after the present date.

For eg. I want to know what date(day, month, year) it will be 200 days from now. Is there any in built function provided by perl to do so?

Find more posts tagged with

Comments

Johnny

take a look at Date::Manip

It is provided in the teamsite distribution.

It provides a ton of date routines including the one you mentioned.

Cant tell you off the top of my head what is was.

print off "perldoc Date::Manip" (its pretty big)

John Cuiuli

gzevin

Hi John,

actually Date::Manip is so smart that it will accept something like '200 days from today' and parse it....

something like:

$date=&ParseDate( '200 days from today' ); ....

or, (which I prefer):

$date=&DateCalc("today","+ 200 days",\$err);

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

nipper

Agreed with the Aussies about Date:Manip it is way cool with one exception. It is slower than a
dog. So if this is a one time gig, no biggie, however if you are using it in a loop over 10K records,
then you may want to rethink using it.

Andy

Johnny

Yeah it is a big bad beast.

But we aren't flying a plane with it, we're using TeamSite... it wouldn't be the bottleneck Smiley Happy

John Cuiuli

herald10

If we write the code for this on our own, instead of using the above mentioned module, will the performance be any better?

Thanks
-H

Dwayne

That depends on how good a coder you are

Generally, however, I would expect that, yes, custom code which meets your specific needs would execute faster than generic code that has to handle a lot of possible variations. There is generally a tradeoff between flexibility and performance.

herald10

Thanks for the info. Well its just that I am coming from a java/C++ background and started using perl. So I was not sure if all the things that worked there work here too! And perl is so flexible that there are a lot of ways to write bad code.

nipper

writing something very specific to do what you want will certainly be faster than using Date::Manip

The question is, is it worth it ? How often will this script run ? Once an hour ? Forget about it. If you
are going to run it over 10K records sequentially ? Get the perl book out. Date::Manip may take (order of
magnitude) 10's to 100s of milliseconds, a regex will be < 1msec. Is that important ?

Andy

herald10

Ofcourse the faster the better. I hate to see my code run slower( Whether it is required for the current project or not).

Dwayne

In reply to:

Ofcourse the faster the better. I hate to see my code run slower

As a programmer, I can sympatize with that statement. However, I've come to realize that it's only true if you add "All else being equal," in front of it. Unfortunately, "all else" is rarely equal.

I certainly don't advocate sloppy coding, but programmers are expensive, while CPU cycles are cheap, relatively speaking. Unless it's going to impact the user experience, that sort of performance tuning is rarely worth the effort. In fact, I often go a little bit in the other direction. When I'm writing a new piece of code, one of the first questions I try to ask myself is "how can I make this more flexible, so that it can be used by somebody else?" Even if that results in a performance hit, it's often worth it to save development effort later.

(this could rapily turn into a programming philosophy debate, which is just a bit OT for this forum.

)

Adam Stoller

I certainly don't advocate sloppy coding, but programmers are expensive, while CPU cycles are cheap, relatively speaking.

Programmers - and in this case - programmers *time*

If you're relatively new to Perl - using the module will probably be faster and less error-prone than writing your own code. However, writing your own code gains you experience (and I think it's fun - but that's me).

As has already been mentioned - the question of whether to write it yourself or use a solid, albeit potentially slower, module is really a question of the need for the extra speed versus the time it will take you to write it, test it, debug it yourself.

In this case - figuring out the correct code to determine 'today + N days' may not be worth your time to re-invent a faster wheel. I'd suggest that you start with the Date::Manip module - get it working and determine if it's fast enough for your purposes. If not - then you can start looking at trying to write your own - but chances are the difference will be in microseconds unless you need to do the calculation 1000 or more times in your program.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

herald10

Thanks Ghoti! That was the exact answer I was looking for.

gzevin

.. especially when date::Manip is a really powerful module, that had been tested by so many people.

yes, I also found it to be slow, but as Johny said, its slowliness was never the major concern of mine, given the fact we have to deal with so many slow stuff around...

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

bboyle

You might be able to use POSIX::strftime to do some of this ...

for example, this will print today's date:
use POSIX;
print strftime('%Y-%m-%d', 0, 0, 0, 2, 8-1, 2004-1900);

the arguments are format, seconds, hours, date, month, year ... month being 0-11 (Jan-Dec) and the year being the current year -1900 (dunno why, it's a perl thing).

This function seems to handle things like "31st February" or even "52nd March" returning the proper date. I've found it very handy. So today being the 2nd of August, if you want to know what the 202nd day of August (2004) is ...
use POSIX;
print strftime('%Y-%m-%d', 0, 0, 0, 2+200, 8-1, 2004-1900);"

And it's ...
2005-02-18

I've no idea how robust this is, but it's done OK for us to date.

Dwayne

In reply to:

This function seems to handle things like "31st February" or even "52nd March" returning the proper date

(emphasis mine)

I would strongly caution against using undocumented "features" like this. If it's not part of the documented API, then there's no guarantee that it will continue to work with the next release. I understand that we have to code with real world contraints, and that sometimes the only way to get done what you need to do is to use undocumented functionality. However, IMO, that should only be when there isn't a reasonable documented alternative. And even then you'd better document that usage extensively. Otherwise the poor programmer who has to maintain your code a year or two from now will have no idea why things are suddenly breaking.

--

Current project: TS 5.5.2/6.1 W2K