Astro-satpass
view release on metacpan or search on metacpan
Uppdates ro canned magnitude table.
Add SECURITY policy.
0.132 2024-09-22 T. R. Wyant
Update canned magnitudes.
Retract deprecation of date2epoch() and epoch2datetime(). When I
decided to retract them (they are unused internally) I neglected to
consider that these consume and generates dates in the Julian
calendar before October 15 1582 Gregorian -- or whatever
$JD_GREGORIAN is set to.
Add Astro::Coord::ECI::Utils::mod360().
Add Astro::Coord::ECI->angular_radius().
0.131 2024-03-16 T. R. Wyant
Deprecate Astro::Coord::ECI::Utils subroutines date2epoch() and
epoch2datetime().
this distribution) passing it commands from a 'here document.' These
commands download International Space Station data from
http://spaceflight.nasa.gov/realdata/elements/ and predict
visibility at the current time from 1600 Pennsylvania Avenue,
Washington DC, USA.
solstice
This Perl script calculates equinoxes and solstices for the given
year, defaulting to the current year, in either UTC or local time.
If DateTime::Calendar::Christian is available, dates will be given
in the Julian or Gregorian calendars as appropriate.
tle_period.t
This is not really a test, since I have no canonical data to test
against. It is really a demonstration of the effect the model chosen
and geophysical constants used have on the calculation of period. It
expects to be run from the main distribution directory as (e.g.)
perl -Mblib eg/tle_period.t
and it expects to find the orbital elements file sgp4-ver.tle in the
eg/solstice view on Meta::CPAN
sub {
my ( $epoch ) = @_;
my @dt_arg;
$opt{reform_date}
and push @dt_arg, reform_date => $opt{reform_date};
my $dt = DateTime::Calendar::Christian->from_epoch(
epoch => $epoch,
time_zone => $zone,
@dt_arg,
);
my $calendar = $dt->is_julian() ? 'Julian' : 'Gregorian';
return $dt->strftime( "%{year_with_era}-%m-%d %H:%M:%S $zone $calendar" );
};
} || do {
$opt{reform_date}
and die "-reform-date requires DateTime::Calendar::Christian\n";
require POSIX;
sub {
my ( $epoch ) = @_;
my @date = $opt{local} ? localtime( $epoch ) : gmtime( $epoch );
$date[4]++;
$date[5] += 1900;
eg/solstice view on Meta::CPAN
can be explicitly negated with C<-nonorthern> (or, equivalently,
C<-southern>.
If both C<-northern> and C<-southern> are specified, either asserted or
negated, the rightmost specification rules.
=head2 -reform-date
-reform-date uk
This option specifies the date the calendar was reformed from Julian to
Gregorian. The specification must be acceptable to
L<DateTime::Calendar::Christian|DateTime::Calendar::Christian>, which
must be loadable.
=head2 -southern
If asserted, this option specifies that the calculation is for the
southern hemisphere. The effect is to exchange spring and fall equinoxes
and summer and winter solstices.
eg/solstice view on Meta::CPAN
This Perl script calculates the GMT dates and times of the equinoxes and
solstices for a given year. The year is specified as the only argument.
If this is omitted, you get the data for the current year.
The year is specified either as a signed number (years since C<1 BC>) or
with a trailing era (C<'AD'>, C<'BC'>, C<'BCE'>, or C<'CE'>,
case-insensitive).
If the L<DateTime::Calendar::Christian|DateTime::Calendar::Christian>
module can be loaded, dates before October 15 1582 will be interpreted
and displayed in the Julian calendar. Otherwise all dates are Gregorian,
and dates less than C<1000AD> are not supported.
=head1 AUTHOR
Tom Wyant (wyant at cpan dot org)
=head1 COPYRIGHT AND LICENSE
Copyright (C) 2016-2025 by Thomas R. Wyant, III
lib/Astro/Coord/ECI/OVERVIEW.pod view on Meta::CPAN
year/month/day to epoch) can be done with core module
L<Time::Local|Time::Local>, but once the year becomes less than 1000, it
means something other than a literal Gregorian year. The
L<DateTime|DateTime> module does not have this limitation, but you need
to be aware that the L<DateTime::TimeZone|DateTime::TimeZone> modules
representing Olson zones (at least the ones I investigated) represent
time before standard time was adopted as local mean time in the zone's
city. C<UTC> does not have this problem, and I believe that offsets and
the C<'floating'> "zone" do not either.
The other problem is that of what calendar is in use. Strictly speaking,
the Julian calendar was in use before the Gregorian calendar was
adopted, at various times ranging from October 15 1542 to April 4 1919,
depending on where you are. If you want Julian-calendar dates,
L<DateTime::Calendar::Christian|DateTime::Calendar::Christian> will
provide dates in the Julian calendar before the reform date (whichever
one you choose to use) and Gregorian dates after. But you need to be a
little careful with it, because it does not implement the full
L<DateTime|DateTime> interface.
One of the resources for comparison data is CalSky
(L<https://calsky.com/>). This does astronomical calculations back to
2999 BC, but there are problems if you go too far back. In particular I
got no Sunrise time for any location I tried before about 1508 BC, and
only one phase of the Moon for the entire month of July 2999 BC. Times
appear to be presented in the Julian calendar before 1543, but I have
not investigated whether they convert on October 15, and I have not yet
found documentation where they say what they are doing. I also have no
idea how they extend time zones back before there were time zones, so I
have asked for times in UTC.
Another resource is Stellarium (L<http://stellarium.org/>, which is
open source planetarium software. I could not figure out how to get
things like equinox/solstice and Moon phases out of it, but rise times
and locations can be obtained just by setting the time appropriately and
then running it. Because resetting the time zone is fairly dodgy, I
simply added five hours to my computed times in UT-5 and reported them.
It does report that times are Gregorian or Julian when you set them. But
instead of setting the year to (e.g.) 2999BC you have to set it to
-2998. The calculations were done with Stellarium 0.15.0.
=head2 Sun
For the Sun I present calculations for the northern solstice in 1508 BC,
that being the earliest one I could find that with sunrise data. Times
are UTC on July 7 1508 BC in the Julian calendar, and sunrise data are
as observed from the Royal Observatory in Greenwich England.
Solstice Sunrise Azimuth
Astro::Coord::ECI::Sun 00:15:46 03:32:32 48.1
CalSky 21h53.8m (1) 3h33.0m 48.1
Stellarium 16:36:57 (2) 03:35:16 48.5
=over
=item 1) The CalSky solstice was on the previous day, July 6. I reported the sunrise data for July 7 because CalSky did not report a Sunrise or sunset on July 6.
lib/Astro/Coord/ECI/Sun.pm view on Meta::CPAN
Historical calculations will need to use a 64-bit Perl, or at least one
with 64-bit integers, to represent times more than about 38 years from
the system epoch.
In addition, you will need to be careful how you do input and output
conversions.
L<Time::Local|Time::Local> is a core module and an obvious choice, but
it only does Gregorian dates. Historical calculations prior to 1587
typically use the Julian calendar. For this you will need to go to
something like L<DateTime::Calendar::Julian|DateTime::Calendar::Julian>,
or L<DateTime::Calendar::Christian|DateTime::Calendar::Christian> which
does either Julian or Gregorian as needed.
Should you decide to use L<Time::Local|Time::Local>, you should be aware
that its C<timegm()> and C<timelocal()> interpret the year argument
strangely: years in the range C<0 - 999> inclusive are not interpreted
as Gregorian years, though years outside that range are so interpreted.
Beginning with version 1.27 (released July 9 2018), additional
subroutines C<timegm_modern()> and C<timelocal_modern()> were added.
lib/Astro/Coord/ECI/Utils.pm view on Meta::CPAN
my $now = time ();
print "The current Julian day is ", julianday ($now);
=head2 UN-DEPRECATION NOTICE
In version 0.131, C<date2epoch()> and C<epoch2datetime()> were
deprecated in favor of C<Time::Local::timegm_posix()> and
C<CORE::gmtime()>.
I later realized that this was wrong. The problem with it was that
astronomical dates are often given in the Julian calendar before October
15 1582, which the previously-recognized subroutines do not handle.
As of version 0.132 the deprecation of these subroutines is retracted,
and all reference to it (other than this notice) will be removed.
=head1 DESCRIPTION
This module was written to provide a home for all the constants and
utility subroutines used by B<Astro::Coord::ECI> and its descendants.
What ended up here was anything that was essentially a subroutine, not
lib/Astro/Coord/ECI/Utils.pm view on Meta::CPAN
=head3 $DATETIMEFORMAT
This variable represents the POSIX::strftime format used to convert
times to strings. The default value is '%a %b %d %Y %H:%M:%S' to be
consistent with the behavior of gmtime (or, to be precise, the
behavior of ctime as documented on my system).
=head3 $JD_GREGORIAN
This variable represents the Julian Day of the switch from Julian to
Gregorian calendars. This is used by date2jd(), jd2date(), and the
routines which depend on them, for deciding whether the date is to be
interpreted as in the Julian or Gregorian calendar. Its initial setting
is 2299160.5, which represents midnight October 15 1582 in the Gregorian
calendar, which is the date that calendar was first adopted. This is
slightly different than the value of 2299161 (noon of the same day) used
by Jean Meeus.
If you are interested in historical calculations, you may wish to reset
this appropriately. If you use date2jd to calculate the new value, be
aware of the effect the current setting of $JD_GREGORIAN has on the
interpretation of the date you give.
=head2 In addition, the following subroutines are exportable:
lib/Astro/Coord/ECI/Utils.pm view on Meta::CPAN
=item $jd = date2jd ($sec, $min, $hr, $day, $mon, $yr)
This subroutine converts the given date to the corresponding Julian day.
The inputs are a Perl date and time; $mon is in the range 0 -
11, and $yr is from 1900, with earlier years being negative. The year 1
BC is represented as -1900.
If less than 6 arguments are provided, zeroes will be prepended to the
argument list as needed.
The date is presumed to be in the Gregorian calendar. If the resultant
Julian Day is before $JD_GREGORIAN, the date is reinterpreted as being
from the Julian calendar.
The only validation is that the month be between 0 and 11 inclusive, and
that the year be not less than -6612 (4713 BC). Fractional days are
accepted.
The algorithm is from Jean Meeus' "Astronomical Algorithms", second
edition, chapter 7 ("Julian Day"), pages 60ff, but the month is
zero-based, not 1-based, and years are 1900-based.
=cut
lib/Astro/Coord/ECI/Utils.pm view on Meta::CPAN
=item $epoch = date2epoch ($sec, $min, $hr, $day, $mon, $yr)
This is a convenience routine that converts the given date to seconds
since the epoch, going through date2jd() to do so. The arguments are the
same as those of date2jd().
If less than 6 arguments are provided, zeroes will be prepended to the
argument list as needed.
The functionality is similar to C<Time::Local::timegm()>, but the
arguments will be interpreted according to the Julian calendar if the
date is before L<$JD_GREGORIAN|/$JD_GREGORIAN>.
=cut
sub date2epoch {
my @args = @_;
__subroutine_deprecation();
unshift @args, 0 while @args < 6;
my ($sec, $min, $hr, $day, $mon, $yr) = @args;
return (date2jd ($day, $mon, $yr) - JD_OF_EPOCH) * SECSPERDAY +
lib/Astro/Coord/ECI/Utils.pm view on Meta::CPAN
subroutine. The day is a whole number, with the fractional part
converted to hours, minutes, and seconds. The $wday is the day of the
week, with Sunday being 0. The $yday is the day of the year, with
January 1 being 0. The trailing 0 is the summer time (or daylight saving
time) indicator which is always 0 to be consistent with gmtime.
If called in scalar context, it returns the date formatted by
POSIX::strftime, using the format string in $DATETIMEFORMAT.
The functionality is similar to C<CORE::gmtime()>, but the result will
be in the Julian calendar if the date is before
L<$JD_GREGORIAN|/$JD_GREGORIAN>.
The input must convert to a non-negative Julian date. The exact lower
limit depends on the system, but is computed by -(JD_OF_EPOCH * 86400).
For Unix systems with an epoch of January 1 1970, this is -210866760000.
Additional algorithms for day of week and day of year come from Jean
Meeus' "Astronomical Algorithms", 2nd Edition, Chapter 7 (Julian Day),
page 65.
lib/Astro/Coord/ECI/Utils.pm view on Meta::CPAN
my $intensity_to_mag_factor; # Calculate only if needed.
sub intensity_to_magnitude {
return - ($intensity_to_mag_factor ||= 2.5 / log (10)) * log ($_[0]);
}
}
=item ($day, $mon, $yr, $greg, $leap) = jd2date ($jd)
This subroutine converts the given Julian day to the corresponding date.
The returns are year - 1900, month (0 to 11), day (which may have a
fractional part), a Gregorian calendar indicator which is true if the
date is in the Gregorian calendar and false if it is in the Julian
calendar, and a leap (or bissextile) year indicator which is true if the
year is a leap year and false otherwise. The year 1 BC is returned as
-1900 (i.e. as year 0), and so on. The date will probably have a
fractional part (e.g. 2006 1 1.5 for noon January first 2006).
If the $jd is before $JD_GREGORIAN, the date will be in the Julian
calendar; otherwise it will be in the Gregorian calendar.
The input may not be less than 0.
The algorithm is from Jean Meeus' "Astronomical Algorithms", second
edition, chapter 7 ("Julian Day"), pages 63ff, but the month is
zero-based, not 1-based, and the year is 1900-based.
=cut
sub jd2date {
( run in 0.685 second using v1.01-cache-2.11-cpan-c333fce770f )