Python Forum
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Julian Day
#11
(Oct-08-2016, 02:09 PM)sparkz_alot Wrote:
(Oct-08-2016, 04:11 AM)Skaperen Wrote:
(Oct-08-2016, 01:41 AM)sparkz_alot Wrote: I'm thinking the simple solution would be to take the absolute value of year, then its a matter of ignoring leap years for that time period. I'll have to give it a try over the weekend, perhaps.

don't forget that 45, 42, 39, 36, 33, 30, 27, 24, 21, 18, 15, 12 and 9 BC are leap years and 4 BC, 0, and 4 AD are not. then leap years are every 4 years until whatever year the transition from Julian to Gregorian was adopted where you are.  are you doing proleptic Gregorian?

what if i entered 1752 for the year, and 9 for September, and a date of 3.  would it reject that date?

i worked out another system that is even more accurate and also simpler, but they would never adopt it.  for it to work, it would have to be adopted before 2028.

now how can someone use this code in their GUI programs?

If you input the date, 1752-9-3 at 1200 hrs, you get a JD of 2361211.0, which jives with US Naval Observatory. As to the years prior to 1752 (though there appears to be some debate on this year) at least from year 8 AD a leap year was every 4 years...period. 
again though, this snag only applies to testing the user input, the formula itself (if given the correct information) is quite accurate.

Quote:i worked out another system that is even more accurate and also simpler, but they would never adopt it.  for it to work, it would have to be adopted before 2028.
 It would be interesting to see.  And you never know, the international committee has been known to adapt  :D

Quote:now how can someone use this code in their GUI programs?

Probably so, but not by me  :D  .

it accepted 1752, 9, 5 when i tried it and it gave a Julian day.  that date did not happen in the British empire (see https://en.wikipedia.org/wiki/1752). try "cal 1752" in a Linux shell and look at September. has this been tested with the BC leap years (e.g. 15 BC, 2, 29 should be valid)?  does it do leap years before 46 BC?  does it handle the varied start of a new year through history? calendar history is complex.  if the tool is applicable to history it too, would be complex.

how would the print calls work in a GUI environment?  will they pop up error windows?
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
#12
Quote:it accepted 1752, 9, 5 when i tried it and it gave a Julian day.  that date did not happen in the British empire (see https://en.wikipedia.org/wiki/1752). try "cal 1752" in a Linux shell and look at September. has this been tested with the BC leap years (e.g. 15 BC, 2, 29 should be valid)?  does it do leap years before 46 BC?  does it handle the varied start of a new year through history? calendar history is complex.  if the tool is applicable to history it too, would be complex.

how would the print calls work in a GUI environment?  will they pop up error windows?
Lets remember, the Julian Day is a count of the number of days, in the case of this formula it is from -4712 thru 2100. The fact that a specific date did not exist, as in the example given, or those in the conversion from the Julian Calendar to the Gregorian Calendar, etc. does not mean that a day did not exist.

"e.g. 15 BC, 2, 29 should be valid?", In the astronomical version of Julian day, yes it is valid and has a Julian Day of 1715638.5, in the historical version of Julian day it is not, in fact it is the equivalent of 16 BC Mar 1. (remembering that the astronomical has a year "0", historical does not)

"if the tool is applicable to history it too, would be complex."  Fortunately it is not concerned with history, only a sequence of days :-)

"how would the print calls work in a GUI environment?  will they pop up error windows?"  I don't know, I will defer that to someone experienced in GUI's
If it ain't broke, I just haven't gotten to it yet.
OS: Windows 10, openSuse 42.3, freeBSD 11, Raspian "Stretch"
Python 3.6.5, IDE: PyCharm 2018 Community Edition
#13
(Oct-09-2016, 02:37 PM)sparkz_alot Wrote:
Quote:it accepted 1752, 9, 5 when i tried it and it gave a Julian day.  that date did not happen in the British empire (see https://en.wikipedia.org/wiki/1752). try "cal 1752" in a Linux shell and look at September. has this been tested with the BC leap years (e.g. 15 BC, 2, 29 should be valid)?  does it do leap years before 46 BC?  does it handle the varied start of a new year through history? calendar history is complex.  if the tool is applicable to history it too, would be complex.

how would the print calls work in a GUI environment?  will they pop up error windows?
Lets remember, the Julian Day is a count of the number of days, in the case of this formula it is from -4712 thru 2100. The fact that a specific date did not exist, as in the example given, or those in the conversion from the Julian Calendar to the Gregorian Calendar, etc. does not mean that a day did not exist.

"e.g. 15 BC, 2, 29 should be valid?", In the astronomical version of Julian day, yes it is valid and has a Julian Day of 1715638.5, in the historical version of Julian day it is not, in fact it is the equivalent of 16 BC Mar 1. (remembering that the astronomical has a year "0", historical does not)

"if the tool is applicable to history it too, would be complex."  Fortunately it is not concerned with history, only a sequence of days :-)

"how would the print calls work in a GUI environment?  will they pop up error windows?"  I don't know, I will defer that to someone experienced in GUI's

what we are basically dealing with is a mapping between a logical system to identify real days (earth rotation) in a linear numeric way (the JD) with a social construct (a calendar system with months and days).  if igot to redesign it, months would be gone and leap years would the common every 4 years as in Gregorin with an exception every 128 years. dates would be seasons and a number, 0 .. 91, accounting for the split days at season boundaries (91.310625 days in a season) ... for example "Winter 35".  the leap day would be inserted (not having a part of any season instead of being added to one) when the accumulated error reaches 12.xxx hours (which then become -11.xxx hours). it's just another social system the has not been adopted (the Gregorian calendar is the official one, not the Skaperenan calendar).

the calendar of choice defines the mapping of history (of choice).  the JD that maps to 2 Sept 1752 should be 1.0 less than the day after it, which is/was 14 Sept 1752.  you could choose the "proleptic Gregorian" calendar, for example.

it would be a slick hack to make a text program pop up the correct GUI windows for UX.  if you make your functions/methods take optional arguments that pass to it callbacks to handle each discrete user interface and let the callback function given handle all input and output, then graceful GUI could be in its future.
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.
#14
Well, I pondered this for quite some time and kept coming back to the same thought, if you follow the rules for a leap year,

the same rules should apply for negative years.
Using Mr. Meuus' formula, this turns out to be true, so the 'simple' fix for the testing portion was to cheat Pythons 'calendar' library.

Substitute this line

days_in_month = monthrange(my_year, my_month)
with this line

days_in_month = monthrange(abs(my_year), my_month)
Using Jean Meeus' examples, the following now compute correctly:
 2000 Jan  1.5      2451545.0
 1987 Jan 27.0      2446822.5
 1987 Jun 19.5      2446966.0
 1988 Jan 27.0      2447187.5
 1900 Jan  1.0      2415020.5
 1600 Jan  1.0      2305447.5
 1600 Dec 31.0      2305812.5
  837 Apr 10.3      2026871.8
-1000 Jul 12.5      1356001.0
-1000 Feb 29.0      1355855.5    ** Note this results in an error, as the year 1000 (-1000) is not a leap year.
-1001 Aug 17.9      1355671.4
-4712 Jan  1.5            0.0

I was all set to do my victory dance until I tried the date 29 Feb 0, which should be a leap year and in fact, by the formula should be JD 1721116.5.... Darn that 'calendar' for starting at year 1.

Well some progress is better than no progress  :smash:
If it ain't broke, I just haven't gotten to it yet.
OS: Windows 10, openSuse 42.3, freeBSD 11, Raspian "Stretch"
Python 3.6.5, IDE: PyCharm 2018 Community Edition
#15
calendar formulations are very hard.  then you have the issue of deciding whether you want to map the simple system like Julian Day to history the way it actually was or the way it should have been.  then is your choice what users need and/or expect.

then is this a UX tool or an algorithm/formula/calculation tool.  and if it is UX, is it CLI or GUI.  if GUI then is it generic or for a specific GUI lib.

the world is not nice and neat.  i had to make these tough decisions back when i was programming in C and made a calendar component for my libh.

are we having fun, yet?
Tradition is peer pressure from dead people

What do you call someone who speaks three languages? Trilingual. Two languages? Bilingual. One language? American.


Forum Jump:

User Panel Messages

Announcements
Announcement #1 8/1/2020
Announcement #2 8/2/2020
Announcement #3 8/6/2020