Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Trouble with time zones and Sun rise/set

by GrandFather (Saint)
on Apr 19, 2022 at 01:42 UTC ( [id://11143067]=perlquestion: print w/replies, xml ) Need Help??

GrandFather has asked for the wisdom of the Perl Monks concerning the following question:

I'm writing a script to generate a report of interesting astronomical events for a specified month. Mostly it's going very well, but I have struck a problem which I suspect is time zone related, but just can't make sense of. The script below is supposed to calculate Sun rise and set times as observed by a telescope in Wellington, New Zealand. Instead it seems to insist on generating UTC times even though the DateTime objects representing the rise and set times know that they are using 'Pacific/Auckland' time. Assuming the times are UTC, they are plausible.

Can anyone see what I'm doing wrong or have misunderstood? (Yes, even in New Zealand in the Southern Hemisphere the sun rises before it sets on the same day.)

use strict; use warnings; use Astro::Coords::Planet; use Astro::Telescope; use DateTime; my %params = ( year => 2022, month => 4, day => 1, hour => 0, minute => 1, second => 0, time_zone => 'Pacific/Auckland', ); my $obsDate = DateTime->new(%params); my $cSun = Astro::Coords->new(planet => 'sun'); $cSun->telescope(Astro::Telescope->new('485')); $cSun->datetime($obsDate); $cSun->datetime()->set_time_zone('Pacific/Auckland'); my $sRise = $cSun->rise_time(); my $sSet = $cSun->set_time(); my $tz = $sRise->time_zone()->name(); print "Rise: $sRise Set: $sSet ($tz)\n";

Prints:

Rise: 2022-04-01T18:34:16 Set: 2022-04-01T06:12:04 (Pacific/Auckland +)

Expected:

Rise: 2022-04-01T06:12:04 Set: 2022-04-01T18:34:16 (Pacific/Auckland +)
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

Replies are listed 'Best First'.
Re: Trouble with time zones and Sun rise/set
by haukex (Archbishop) on Apr 19, 2022 at 06:03 UTC
    Expected: Rise: 2022-04-01T06:12:04 Set: 2022-04-01T18:34:16 (Pacific/Auckland)

    I am wondering where you're getting these from, since they don't seem to match any information I could find. My results below do match those from timeanddate.com. Even if you fiddle with DateTime::Event::Sunrise's altitude parameter as per "Sun Height" in its documentation, I don't get the same times. For Astro::Coords, the only reference to time zones in its documentation is "A copy of the input argument is created, guaranteeing a UTC representation." - so I figured it's best to just work with UTC inside the module, and only convert to local time zone once one gets the results. I think the slight deviation between the two modules could be because Astro::Coords takes the altitude into account, or some other minor inaccuracy.

    use strict; use warnings; use Astro::Coords; use Astro::Telescope; use DateTime::Event::Sunrise; use DateTime; my %params = ( year => 2022, month => 4, day => 1, hour => 0, minute => 1, second => 0, time_zone => 'Pacific/Auckland' ); my $obsDate = DateTime->new(%params); $obsDate->set_time_zone('UTC'); my $tel = Astro::Telescope->new('485'); print "Lat=", $tel->lat('d'), " Lon=", $tel->long('d'), " Alt=", $tel->alt, "\n"; my $cSun = Astro::Coords->new(planet => 'sun'); $cSun->telescope($tel); $cSun->datetime($obsDate); my $sRise = $cSun->rise_time(); my $sSet = $cSun->set_time(); $sRise->set_time_zone('Pacific/Auckland'); $sSet ->set_time_zone('Pacific/Auckland'); print "Rise: ",$sRise->strftime('%FT%T %Z'), " Set: ",$sSet ->strftime('%FT%T %Z'),"\n"; my $sun = DateTime::Event::Sunrise->new( altitude=>-0.833, longitude => $tel->long('d'), latitude => $tel->lat('d') ); $obsDate->add(days=>1); # not sure yet why the two modules differ here my $rise2 = $sun->sunrise_datetime($obsDate); my $set2 = $sun-> sunset_datetime($obsDate); $rise2->set_time_zone('Pacific/Auckland'); $set2 ->set_time_zone('Pacific/Auckland'); print "Rise: ",$rise2->strftime('%FT%T %Z'), " Set: ",$set2 ->strftime('%FT%T %Z'),"\n"; __END__ Lat=-41.2842368910727 Lon=174.7654 Alt=144.005447541833 Rise: 2022-04-01T07:35:56 NZDT Set: 2022-04-01T19:13:17 NZDT Rise: 2022-04-01T07:36:11 NZDT Set: 2022-04-01T19:13:42 NZDT

    Update: For Solstice/Equinox, see my script at Re: calculate length of day as function of space at onset of fall.

      not sure yet why the two modules differ here

      Astro::Coords returns the next sunrise/sunset after the provided timestamp.

      DateTime::Event::Sunrise returns the sunrise/sunset for the provided date.

      You should have used

      $obsDate->set_time_zone('Pacific/Auckland');
      instead of
      $obsDate->add(days=>1);

      Most of the time zone mess is due to the evolution of this project. I'm taking over generating a report of visibility of solar system objects for the next month. The person doing this before me used Guide 9 to generate Sun and planet rise/set times and various other details. He manually transcribed various tables then added other events of note. Manually transcribing tables was not appealing so I reached for Perl. I started by parsing the tables and formatting them for a website, then started adding planet and star conjunction detection for the "other details" section. That is when things came unstuck with a mixture of time zones depending on where data originally came from.

      Thanks again for the help.

      Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

      Thank you! Setting the time zone to UTC for the DateTime given to Astro::Coords fixes the problem. I'll follow up later with a little more detail, but right now I'm about to head out the door on holiday.

      Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

        Please post revised source. I'm fascinated by the view from "down under," which I have never experienced in real life. I'll see if I can replicate your results.

Re: Trouble with time zones and Sun rise/set
by cavac (Parson) on Apr 21, 2022 at 14:35 UTC

    For even more precision, you should check if the Astro:: modules use UTC (Coordinated universal time) or TAI (international atomic time). UTC includes leap seconds, TAI doesn't (which is why TAI is prefered for space related stuff like astronomy and orbital parameters).

    Currently, the offset UTC-TAI = -37s, but you should regularly (January and July) check against the International Earth Rotation and Reference Systems (IERS) Bulletin C for any upcoming leap second changes.

    37 seconds doesn't sound like much, but when you use a big telescope, it can mean the difference between getting a nice picture of the crab nebula or getting a picture of something else that is up to 0.15 degrees (9 arcminutes?) away from the center of the crab nebula, if my math is correct.

    perl -e 'use Crypt::Digest::SHA256 qw[sha256_hex]; print substr(sha256_hex("the Answer To Life, The Universe And Everything"), 6, 2), "\n";'

      The Astro::Coords modules use UTC. For my current project I'm just interested in providing a report for naked eye and maybe binocular observers so the TAI/UTC disparity doesn't matter. The software I use for pointing telescopes does know about such things, but I don't have to worry about it. Much more important is to remember that the software's default epoch is JNow which is almost never correct and that I have to bludgeon it into using J2000 to get things pointed correctly!

      Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
Re: Trouble with time zones and Sun rise/set
by syphilis (Archbishop) on Apr 19, 2022 at 02:40 UTC
    Hi GrandFather,

    Perhaps the module has an embedded April Fools Day prank ?
    ;-))

    Cheers,
    Rob

      Alas, it's not that simple. If I change the date to the 2nd I get:

      Rise: 2022-04-02T18:35:20 Set: 2022-04-02T06:10:25 (Pacific/Auckland +)

      which is altogether consistent with the Sun rising a little later each day as we head into winter assuming the reported time is UTC and we are in the Southern Hemisphere.

      Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
        Another odd thing I've just noticed is that you're "expected" result has sunset being significantly more than 12 hours after sunrise - yet April comes along after the March (autumn) equinox.

        Cheers,
        Rob

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://11143067]
Approved by kcott
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having a coffee break in the Monastery: (6)
As of 2024-03-29 10:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found