| Re: Julian Day Question [message #48851] |
Tue, 30 May 2006 16:02  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Mark Hadfield writes:
> It is not useful to ask how it *should* work and *why* it works the way
> it does. It is only useful to observe *how * it works and find a way of
> coping with it.
Yeah, no matter how ugly the baby, there is always
a proud parent somewhere. :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Julian Day Question [message #48853 is a reply to message #48851] |
Tue, 30 May 2006 15:46  |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
Paul Van Delst wrote:
> However, it the two julday results up top still seem inconsistent. If
> I'm an astronomer and my day start reference for input to the julday
> routine is 12 noon, then why do julday(1,1,1,0,0,0) and julday(1,1,1)
> provide different results? Doesn't julday(1,1,1,0,0,0) refer to 0hours,
> 0minutes, 0seconds beyond the (12noon) start of the day? Why does
> providing the ",0,0,0" hh,mm,ss data cause the start reference to
> suddenly shift by 12 hours?
It is not useful to ask how it *should* work and *why* it works the way
it does. It is only useful to observe *how * it works and find a way of
coping with it.
--
Mark Hadfield "Kei puwaha te tai nei, Hoea tahi tatou"
m.hadfield@niwa.co.nz
National Institute for Water and Atmospheric Research (NIWA)
|
|
|
|
|
|
|
|
|
|
| Re: Julian Day Question [message #48867 is a reply to message #48866] |
Fri, 26 May 2006 10:09 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Wayne Landsman wrote:
> Paul Van Delst wrote:
>
>
>> However, it the two julday results up top still seem inconsistent. If I'm an astronomer
>> and my day start reference for input to the julday routine is 12 noon, then why do
>> julday(1,1,1,0,0,0) and julday(1,1,1) provide different results? Doesn't
>> julday(1,1,1,0,0,0) refer to 0hours, 0minutes, 0seconds beyond the (12noon) start of the
>> day? Why does providing the ",0,0,0" hh,mm,ss data cause the start reference to suddenly
>> shift by 12 hours?
>>
>
>
> The way I think about it is that there are two distinct quanities: an
> integral "Julian Day" and a real-valued "Julian Date". For example,
> from the US Naval Observatory Website
> http://tycho.usno.navy.mil/systime.html
>
> **
> Julian Day Number is a count of days elapsed since Greenwich mean noon
> on 1 January 4713 B.C., Julian proleptic calendar. The Julian Date is
> the Julian day number followed by the fraction of the day elapsed
> since the preceding noon.
> ***
Ah. Now it becomes clear. Apples [julday(1,1,1,0,0,0)] vs. oranges [julday(1,1,1)].
> So when you supply the IDL julday() function with only the day, month
> and year, it calculates the integral Julian day (and returns a
> longword). If you also supply the hh,mm,ss (even if this is 0,0,0)
> then it returns a double precision Julian date. --Wayne
Thanks,
paulv
--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
Ph: (301)763-8000 x7748
Fax:(301)763-8545
|
|
|
|
| Re: Julian Day Question [message #48868 is a reply to message #48867] |
Fri, 26 May 2006 10:05 |
news.qwest.net
Messages: 137
Registered: September 2005
|
Senior Member |
|
|
"Paul Van Delst" <Paul.vanDelst@noaa.gov> wrote in message
news:e57e90$6ri$1@news.nems.noaa.gov...
> Why does providing the ",0,0,0" hh,mm,ss data cause the start reference to
> suddenly shift by 12 hours?
Yes, that is exactly the problem. The function breaks one of the fundamental
tenets of software programming. It does 2 different things (depending on
the input).
1) convert to julian day (noon based)
2) (a) convert to julian day and (b) convert to midnight based
Hence my suggestion to hardwire the function to always perform one function.
I propose that always inputting the h:m:s and forcing the result to return
the midnight
based julian day, which is what i do in my little library of time functions.
Cheers,
bob
PS I should admit that I almost always break this tenet of programming.
I write routines that are overloaded to "do what you want it to" :O
But then again, I am a hack :)
|
|
|
|
| Re: Julian Day Question [message #48869 is a reply to message #48868] |
Fri, 26 May 2006 09:57 |
news.verizon.net
Messages: 47
Registered: August 2003
|
Member |
|
|
Paul Van Delst wrote:
> However, it the two julday results up top still seem inconsistent. If I'm an astronomer
> and my day start reference for input to the julday routine is 12 noon, then why do
> julday(1,1,1,0,0,0) and julday(1,1,1) provide different results? Doesn't
> julday(1,1,1,0,0,0) refer to 0hours, 0minutes, 0seconds beyond the (12noon) start of the
> day? Why does providing the ",0,0,0" hh,mm,ss data cause the start reference to suddenly
> shift by 12 hours?
>
The way I think about it is that there are two distinct quanities: an
integral "Julian Day" and a real-valued "Julian Date". For example,
from the US Naval Observatory Website
http://tycho.usno.navy.mil/systime.html
**
Julian Day Number is a count of days elapsed since Greenwich mean noon
on 1 January 4713 B.C., Julian proleptic calendar. The Julian Date is
the Julian day number followed by the fraction of the day elapsed
since the preceding noon.
***
So when you supply the IDL julday() function with only the day, month
and year, it calculates the integral Julian day (and returns a
longword). If you also supply the hh,mm,ss (even if this is 0,0,0)
then it returns a double precision Julian date. --Wayne
|
|
|
|
| Re: Julian Day Question [message #48870 is a reply to message #48869] |
Fri, 26 May 2006 09:53 |
news.qwest.net
Messages: 137
Registered: September 2005
|
Senior Member |
|
|
> JULDAY(5,26,2006, 0,0,0)
> JULDAY(5,26,2006)
My 2cents, to quote buffy, "It doesn't matter".
I always start with a modern date string, then convert
to JD to do all the processing, etc, and then convert
back to strings for output/ plotting etc. What the
dates convert to doesn't matter, as long as one is consistent
(i always input hours minutes and seconds.)
It seems to me the "problem" is between an integer day, and
a much more precise millisecond representation.
If someone asks what day number today is (of this month)
people will say the 26th. No one will say the 26.4486th.
However, if someone wants the exact time of this post, then
you would say it was posted on May 26.4486th MT.
I do admit though, that knowing that the julian day is actually
noon twelve hours earlier is a nice little secret to have.
Anyways, the conclusion should be:
always be consistent
(simply saying "be consistent" doesn't seem redundant enough)
Cheers,
bob
PS I'd put an n_params() check on the
julday function wrapper if I were me (to ensure
hours minutes and seconds were always passed).
|
|
|
|
| Re: Julian Day Question [message #48871 is a reply to message #48870] |
Fri, 26 May 2006 09:43 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
kuyper@wizard.net wrote:
> Paul Van Delst wrote:
> ...
>
>> The example on that page is:
>>
>> IDL> print, julday(1,1,1,0,0,0), julday(1,1,1)
>> 1721423.5 1721424
>>
>> The *input* date, 0001-01-01, /should/ be based on how we define dates /now/, starting at
>> midnight. But the reference point for the input date seems to change (to 12noon) when the
>> hours/minutes/seconds are not supplied.
>
>
> It is based upon how dates are defined now - by astronomers.
Yeah, I realised that after I read subsequent posts. And, for that application, it makes
perfect sense.
However, it the two julday results up top still seem inconsistent. If I'm an astronomer
and my day start reference for input to the julday routine is 12 noon, then why do
julday(1,1,1,0,0,0) and julday(1,1,1) provide different results? Doesn't
julday(1,1,1,0,0,0) refer to 0hours, 0minutes, 0seconds beyond the (12noon) start of the
day? Why does providing the ",0,0,0" hh,mm,ss data cause the start reference to suddenly
shift by 12 hours?
paulv
> The Julian
> day starts at 12:00 noon, because that means an entire night's data
> get's tagged with the same Julian date. The Julian date system was
> originally invented to help astronomers match up ancient records of
> astronomical events with modern observations, to get more accurate
> figures for things like the orbital period of a comet. The starting
> point was chosen because calender cycles associated with several
> different popular historical calendar systems all come together on that
> date. This simplifies the process of converting between the Julian date
> and any one of those calendar systems.
>
--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
Ph: (301)763-8000 x7748
Fax:(301)763-8545
|
|
|
|
| Re: Julian Day Question [message #48872 is a reply to message #48871] |
Fri, 26 May 2006 09:20 |
James Kuyper
Messages: 425
Registered: March 2000
|
Senior Member |
|
|
Paul Van Delst wrote:
...
> The example on that page is:
>
> IDL> print, julday(1,1,1,0,0,0), julday(1,1,1)
> 1721423.5 1721424
>
> The *input* date, 0001-01-01, /should/ be based on how we define dates /now/, starting at
> midnight. But the reference point for the input date seems to change (to 12noon) when the
> hours/minutes/seconds are not supplied.
It is based upon how dates are defined now - by astronomers. The Julian
day starts at 12:00 noon, because that means an entire night's data
get's tagged with the same Julian date. The Julian date system was
originally invented to help astronomers match up ancient records of
astronomical events with modern observations, to get more accurate
figures for things like the orbital period of a comet. The starting
point was chosen because calender cycles associated with several
different popular historical calendar systems all come together on that
date. This simplifies the process of converting between the Julian date
and any one of those calendar systems.
|
|
|
|
| Re: Julian Day Question [message #48873 is a reply to message #48872] |
Fri, 26 May 2006 07:20 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
David Fanning wrote:
> David Fanning writes:
>
>
>> Clearly, I am missing something important here. :-(
>
>
> Oh, wait! I am missing Mark's nice explanation of this
> problem on my very own web page. Sigh..
>
> http://www.dfanning.com/misc_tips/julianday.html
>
> But even after reading it, I'm very, very confused. :-(
Me too - it seems inconsistent.
The example on that page is:
IDL> print, julday(1,1,1,0,0,0), julday(1,1,1)
1721423.5 1721424
The *input* date, 0001-01-01, /should/ be based on how we define dates /now/, starting at
midnight. But the reference point for the input date seems to change (to 12noon) when the
hours/minutes/seconds are not supplied.
paulv
p.s. Mark's point (about using such a distant reference point for dates) is also a good
one. Why Julian and not, say, Gregorian dates? (At least for those of us that use the
Gregorian calendar). Another (somewhat) common reference I've encountered in satellite
data streams is the number of seconds since Jan 1, 1980, 00:00:00 - which makes more sense
to me that julian dates.
--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
Ph: (301)763-8000 x7748
Fax:(301)763-8545
|
|
|
|
| Re: Julian Day Question [message #48874 is a reply to message #48873] |
Fri, 26 May 2006 07:17 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Mike Wallace writes:
> I should have added that I always specify hours minutes and seconds when
> working with julday() for this very reason and because I specify the
> time within the day, I get what I expect. Come to think of it, julday()
> without the hours minutes and seconds also gives me what I expect
I'm going to think of it like this, which makes a weird
kind of sense to me:
If you specify ONLY a year, month, and day (in whatever
mixed up order you like [who wrote JULDAY, anyway!!]) then
clearly you must be concerned with a calendar DATE. So
having JULDAY return the date of the day that really
started at midnight is OK with me.
However, if you also specify the hour, minute, and second,
you must clearly be an astronomer (who else would care!?)
and JULDAY will return the astronomically correct Julian Day.
At least this is something I can remember...maybe.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Julian Day Question [message #48875 is a reply to message #48874] |
Fri, 26 May 2006 07:05 |
Mike Wallace
Messages: 25
Registered: May 2006
|
Junior Member |
|
|
> My experience is that the naive usage of the IDL JULDAY function does
> not give me what I expect to see. For a given calendar date, say
> JULDAY(5,26,2006), I normally expect this to refer to midnight at the
> start of the day (JD 2453881.5), whereas IDL returns the Julian day at
> noon, twelve hours later (JD 2453882). Of course, if one specifies
> hours, minutes and seconds, then the proper result pops out.
>
> I.e., I would naively expect these to be the same but they are not:
> JULDAY(5,26,2006, 0,0,0)
> JULDAY(5,26,2006)
I should have added that I always specify hours minutes and seconds when
working with julday() for this very reason and because I specify the
time within the day, I get what I expect. Come to think of it, julday()
without the hours minutes and seconds also gives me what I expect,
however what I expect is a weird number because some astronomer thought
he was being smart by having the day boundary be at a time when he
wouldn't be observing. I guess it has to deal with your expectations
and since I've looked at Julian Day numbers and other weird time systems
for years now, I've become conditioned to it. After working with
things like Ephemeris Time and Barycentric Dynamical Time, Julian Day
seems pretty easy. :-)
-Mike
|
|
|
|
|
|
|
|
| Re: Julian Day Question [message #48878 is a reply to message #48877] |
Thu, 25 May 2006 23:28 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Craig Markwardt writes:
> I.e., I would naively expect these to be the same but they are not:
> JULDAY(5,26,2006, 0,0,0)
> JULDAY(5,26,2006)
Well, I am *definitely* in the naive category, and this is
certainly what I expected, if that confirms your theory at all. :-)
This must seem strange to somebody other than us virgins.
What do those folks make of it?
Cheers,
David
P.S. I realize it is almost a sacrilege to have worked with
IDL for as long as I have and still be surprised by something
like this, but they you go. Naive as the day I was born!
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
|
|
| Re: Julian Day Question [message #48880 is a reply to message #48879] |
Thu, 25 May 2006 22:52 |
Craig Markwardt
Messages: 1869
Registered: November 1996
|
Senior Member |
|
|
Mike Wallace <mwallace.no.spam.please@swri.edu.invalid> writes:
>> Anyone have any ideas about this? Is a Julian Day number
>> a "standard" in the sense that OpenGL is a standard?
>
> Julian Day is simply the number of days past 12 noon UTC on January 1,
> 4713 BC. Nothing more. Nothing less. However I have seen people use
> the term "Julian Day" for a quantity that is not actually a Julian
> Day, but something derived from a Julian Day. There are Modified
> Julian Days and Truncated Julian Days and Reduced Julian Days among
> many others. There's also a Julian Year, but despite the name it has
> absolutely no relationship to Julian Days.
>
> I will say that the IDL Julian Day routines give me what I expect to
> see. Perhaps the others are just variations.
My experience is that the naive usage of the IDL JULDAY function does
not give me what I expect to see. For a given calendar date, say
JULDAY(5,26,2006), I normally expect this to refer to midnight at the
start of the day (JD 2453881.5), whereas IDL returns the Julian day at
noon, twelve hours later (JD 2453882). Of course, if one specifies
hours, minutes and seconds, then the proper result pops out.
I.e., I would naively expect these to be the same but they are not:
JULDAY(5,26,2006, 0,0,0)
JULDAY(5,26,2006)
Craig
--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@REMOVEcow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
|
|
|
|
| Re: Julian Day Question [message #48881 is a reply to message #48880] |
Thu, 25 May 2006 23:13 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
David Fanning writes:
> Consider:
>
> IDL> Print, JULDAY(1, 1, 1999) ; 1 Jan 1999
> 2451180
>
> This is the wrong answer according to Meeus, who lists the
> answer as 2451179.5.
>
> But, then consider this, which should be the SAME time:
>
> IDL> Print, JULDAY(1, 1, 1999, 0) ; 1 Jan 1999 at 0 hours
> 2451179.5
>
> What do you make of that?
Here is the same thing, but with JHUAPL routines:
IDL> Print, YMD2JD(1999, 1, 1)
2451180
But, converting first to "Julian seconds", and then to the Julian
Day:
IDL> js = YMDS2JS(1999, 1, 1, 0)
IDL> Print, JS2JD(js)
2451179.5
Clearly, I am missing something important here. :-(
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
| Re: Julian Day Question [message #48882 is a reply to message #48880] |
Thu, 25 May 2006 23:03 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Mike Wallace writes:
> I will say that the IDL Julian Day routines give me what I expect to
> see. Perhaps the others are just variations.
Ah, well, maybe what I am seeing is a feature. :-)
Consider:
IDL> Print, JULDAY(1, 1, 1999) ; 1 Jan 1999
2451180
This is the wrong answer according to Meeus, who lists the
answer as 2451179.5.
But, then consider this, which should be the SAME time:
IDL> Print, JULDAY(1, 1, 1999, 0) ; 1 Jan 1999 at 0 hours
2451179.5
What do you make of that?
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
|
|
| Re: Julian Day Question [message #48910 is a reply to message #48853] |
Fri, 02 June 2006 10:03 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Mark Hadfield wrote:
> Paul Van Delst wrote:
>
>> However, it the two julday results up top still seem inconsistent. If
>> I'm an astronomer and my day start reference for input to the julday
>> routine is 12 noon, then why do julday(1,1,1,0,0,0) and julday(1,1,1)
>> provide different results? Doesn't julday(1,1,1,0,0,0) refer to
>> 0hours, 0minutes, 0seconds beyond the (12noon) start of the day? Why
>> does providing the ",0,0,0" hh,mm,ss data cause the start reference to
>> suddenly shift by 12 hours?
>
>
>
> It is not useful to ask how it *should* work and *why* it works the way
> it does. It is only useful to observe *how * it works and find a way of
> coping with it.
Ha ha! In the real world, maybe. But this is c.l.i.p!
:o)
paulv
p.s. BTW, does your boss at NIWA know that you never fix busted software?!? :o)
--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx
Ph: (301)763-8000 x7748
Fax:(301)763-8545
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
