DateAndTime>julianDayNumber

Hi All,

I'm playing around with trying to calculate sunrise and sunset times.  That requires using Julian dates/times (a float based on noon ‎Greenwich Mean Time).  DateAndTime>julianDayNumber uses the date value of the DateAndTime instance ignoring the timezone of the instance.  Should the DateAndTime instance be adjusted to #UTC and then use that to calculate the julianDayNumber?

Lou

Hi again,

To be clear, #julianDayNumber code calls #year and #year calls #date.  Actually #julianDayNumber needs year, month and day of month, perhaps some math can be used to calculate those values without the adjustment to the timezone of the instance, thereby not needing it to be adjusted to UTC to get the correct values.

Lou

On Thursday, November 19, 2015 at 10:02:35 AM UTC-5, Louis LaBrunda wrote:

Hi Donald,

I thought about it some more and I think it does matter.  The julianDayNumber code calls #date.  For some times of the day, #date answers a different date.  This results in a different julianDayNumber.  Execute the following code and you will see two different dates and julianDayNumbers.  Since Julian dates are based on noon ‎Greenwich Mean Time I think the DateAndTime needs to be adjusted to UTC and that instance used to calculate julianDayNumber.

| dt dtL |

dtL := DateAndTime year: 2015 month: 11 day: 19 hour: 23 minute: 2 second: 3 timeZone: #'America/New_York'.

dtL date inspect.

dtL julianDayNumber inspect.

"dt := dtL transformToTimeZoneNamed: #UTC."

dt := dtL asUTC.

dt date inspect.

dt julianDayNumber inspect.

Lou

On Wednesday, November 18, 2015 at 5:15:21 PM UTC-5, Donald MacQueen wrote:

Hi Lou

I do not think it matters. Here's why

If I inspect DateAndTime year: 2015 day: 350 hour: 22 minute: 0 second: 0 I get 2015-12-16T22:00:00-05:00 because my timeZone is America\New_York

If I send asUTC to that DateAndTime instance I get: 2015-12-17T03:00:00+00:00.

Both these DateAndTime instances are the same instance in time; they both have milliSeconds of 3627774000000, and differ only in their timeZone.

Sending julianDayNumber to each of them in turn results in 2457374 for both.

hth,

Donald [|]



On Wednesday, November 18, 2015 at 11:51:59 AM UTC-5, Louis LaBrunda wrote:

Hi All,

I'm playing around with trying to calculate sunrise and sunset times.  That requires using Julian dates/times (a float based on noon ‎Greenwich Mean Time).  DateAndTime>julianDayNumber uses the date value of the DateAndTime instance ignoring the timezone of the instance.  Should the DateAndTime instance be adjusted to #UTC and then use that to calculate the julianDayNumber?

Lou

Hi Lou,

I guess it depends what timezone the sunrise and sunset times are.

On Thursday, November 19, 2015 at 10:12:04 AM UTC-5, Louis LaBrunda wrote:

Hi again,

To be clear, #julianDayNumber code calls #year and #year calls #date.  Actually #julianDayNumber needs year, month and day of month, perhaps some math can be used to calculate those values without the adjustment to the timezone of the instance, thereby not needing it to be adjusted to UTC to get the correct values.

Lou

On Thursday, November 19, 2015 at 10:02:35 AM UTC-5, Louis LaBrunda wrote:

Hi Donald,

I thought about it some more and I think it does matter.  The julianDayNumber code calls #date.  For some times of the day, #date answers a different date.  This results in a different julianDayNumber.  Execute the following code and you will see two different dates and julianDayNumbers.  Since Julian dates are based on noon ‎Greenwich Mean Time I think the DateAndTime needs to be adjusted to UTC and that instance used to calculate julianDayNumber.

| dt dtL |

dtL := DateAndTime year: 2015 month: 11 day: 19 hour: 23 minute: 2 second: 3 timeZone: #'America/New_York'.

dtL date inspect.

dtL julianDayNumber inspect.

"dt := dtL transformToTimeZoneNamed: #UTC."

dt := dtL asUTC.

dt date inspect.

dt julianDayNumber inspect.

Lou

On Wednesday, November 18, 2015 at 5:15:21 PM UTC-5, Donald MacQueen wrote:

Hi Lou

I do not think it matters. Here's why

If I inspect DateAndTime year: 2015 day: 350 hour: 22 minute: 0 second: 0 I get 2015-12-16T22:00:00-05:00 because my timeZone is America\New_York

If I send asUTC to that DateAndTime instance I get: 2015-12-17T03:00:00+00:00.

Both these DateAndTime instances are the same instance in time; they both have milliSeconds of 3627774000000, and differ only in their timeZone.

Sending julianDayNumber to each of them in turn results in 2457374 for both.

hth,

Donald [|]



On Wednesday, November 18, 2015 at 11:51:59 AM UTC-5, Louis LaBrunda wrote:

Hi All,

I'm playing around with trying to calculate sunrise and sunset times.  That requires using Julian dates/times (a float based on noon ‎Greenwich Mean Time).  DateAndTime>julianDayNumber uses the date value of the DateAndTime instance ignoring the timezone of the instance.  Should the DateAndTime instance be adjusted to #UTC and then use that to calculate the julianDayNumber?

Lou

Hi Donald,

I have extended DateAndTime with the method below.  It answers a Julian date that includes the time of day (as part of the fraction part of the float that is the Julian date).  It is similar to the VA Smalltalk DateAndTime>julianDayNumber code with two changes.  First, I have corrected the problem caused by calling the #year method that calls the #date method that returns a date that includes the offset from UTC.  This is a bug in the #julianDayNumber code (I don't say that lightly).  The algorithm assumes that the date used is sometime after noon UTC.  With the offset used, the date isn't.  Second, I incorporate the time part of DateAndTime to get a Julian date with the time included.

julianDate

"Answer the Julian date (a Float) from our date and time.  Valid for all dates after 4800 BC."

| utcDate year month day ut jd a y m |

utcDate := Date fromDays: (milliseconds // (MillisecondsPerSecond * SecondsPerDay)).

year := utcDate year.

month := utcDate monthIndex.

day := utcDate dayOfMonth.

ut := ((Time fromMilliseconds: milliseconds) asMilliseconds / MillisecondsPerSecond / SecondsPerDay) asFloat.

a := (14 - month) quo: 12.

y := year + 4800 - a.

m := month + (12 * a) - 3.

jd := day + ((153 * m + 2) quo: 5) + (365 * y) + (y quo: 4) - (y quo: 100) + (y quo: 400) - 32045 - 0.5 + ut.

^jd.

Your first post about the milliSeconds being the same for two DateAndTime instances for the same time with different time zones proves the bug.  Two identical instances of DateAndTime with different time zones should always answer the same julianDayNumber, they don't.  My example of "DateAndTime year: 2015 month: 11 day: 19 hour: 23 minute: 2 second: 3 timeZone: #'America/New_York'." proves that.

 

In another post I mentioned having #julianDayNumber call my #julianDate with a little code to remove the time part.  When I wrote that I forgot about the algorithm for #julianDayNumber assuming that is is noon on the day in question.  Therefor I would just fix #julianDayNumber to use code that did not include the time zone offset and that's it and not call #julianDate.

I have also extended Date with #julianDayNumber and #julianDate where there is not time zone and therefor no offset and the date can just be assumed to be after noon UTC time.  This seems like a better home for #julianDayNumber where we don't have to deal with the time zone offset and we don't have to ignore the time part of a DateAndTime.

Now to press on and see if I can calculate sunrise and sunset.

Lou