Why not adopt me?
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 <email@example.com> with help from previous work by Kurt Jaeger aka PI <firstname.lastname@example.org> based on postings from: Ian Miller <email@example.com>; Gary Puckering <firstname.lastname@example.org> 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 email@example.com.