Time::JulianDay -- Julian calendar manipulations
use Time::JulianDay
$jd = julian_day($year, $month_1_to_12, $day)
$jd = local_julian_day($seconds_since_1970);
$jd = gm_julian_day($seconds_since_1970);
($year, $month_1_to_12, $day) = inverse_julian_day($jd)
$dow = day_of_week($jd)
print (Sun,Mon,Tue,Wed,Thu,Fri,Sat)[$dow];
$seconds_since_jan_1_1970 = jd_secondslocal($jd, $hour, $min, $sec)
$seconds_since_jan_1_1970 = jd_secondsgm($jd, $hour, $min, $sec)
$seconds_since_jan_1_1970 = jd_timelocal($sec,$min,$hours,$mday,$month_0_to_11,$year)
$seconds_since_jan_1_1970 = jd_timegm($sec,$min,$hours,$mday,$month_0_to_11,$year)
JulianDay is a package that manipulates dates as number of days since some time a long time ago. It's easy to add and subtract time using julian days...
The day_of_week returned by day_of_week() is 0 for Sunday, and 6 for Saturday and everything else is in between.
Time::JulianDay is not a correct implementation. There are two problems. The first problem is that Time::JulianDay only works with integers. Julian Day can be fractional to represent time within a day. If you call inverse_julian_day() with a non-integer time, it will often give you an incorrect result.
The second problem is that Julian Days start at noon rather than midnight. The julian_day() function returns results that are too large by 0.5.
What to do about these problems is currently open for debate. I'm tempted to leave the current functions alone and add a second set with more accurate behavior.
There is another implementation in Astro::Time that may be more accurate.
Written by David Muir Sharnoff <cpan@dave.sharnoff.org> with help from previous work by Kurt Jaeger aka PI <zrzr0111@helpdesk.rus.uni-stuttgart.de> based on postings from: Ian Miller <ian_m@cix.compulink.co.uk>; Gary Puckering <garyp%cognos.uucp@uunet.uu.net> based on Collected Algorithms of the ACM ?; and the unknown-to-me author of Time::Local.
Copyright (C) 1996-1999 David Muir Sharnoff. License hereby granted for anyone to use, modify or redistribute this module at their own risk. Please feed useful changes back to cpan@dave.sharnoff.org.