# JDay Datatype in Grasshopper/Heliotrope

Handling dates and times in software is a tricky business. Take .Net”s commonly used DateTime data structure. This seemingly simple type is cluttered with details specific to the needs of the the windows-pc operating system and not at all well suited to the 3d modeler. For example, it knows the physical location of your computer: if you request a date in local time, it is returned in the local timezone where you live. But what if your site is located in Timbuktu instead of your home town? (Assuming you don’t live in Timbuktu that is!) DateTimes won’t let you reference a third location. And DateTime calculations are based upon “ticks.” How long is a tick? How many of them are there in a day? (FYI: 100 nanoseconds and 86,400,000,000,000/100)

All this is useful if you want to format a calendar date according to local custom, not particularly in astronomical calculations or quick manipulations in Grasshopper. Heliotrope instead provides the JDay, or Julian Day, datatype. Julian Days are a more or less standardized astronomical date value (see the Wikipedia article) and Heliotrope’s are specifically based upon the definition given by Jean Meeus in his 1991 text “Astronomical Algorithms“.

The integer portion of a Julian Day value specifies the date and decimal portion the period of time on that date as a fraction of the 24 hour period. The value of defining a special Grasshopper datatype is that dates may then be converted to and from other datatypes to take advantage of additional standard components. For instance, they may be converted to and from strings for setting or display. Math components can add days or portions of days to the value without having to calculate the corresponding number of clock ticks. One oft-used example is to generate JDay values for sunrise and sunset, then subtract the two to give the time period between. When this result is multiplied by a value between 0 and 1 (controlled by a slider) and added back onto the sunrise, a parametric control is created that adjusts the time of day between sunrise and sunset.

Of course there are additional hidden details. Historically, a Julian Day value of 0.0 references the calendar date of noon on January 1, 4712bc, and this is the base point used in solar calculations. The number of digits of accuracy required to correctly represent a current Julian Day value, however, exceeds the accuracy available in a double precision value and this can result in seconds of error in simple time calculations. Thus, when casting to and from a Grasshopper “number” value (a double under the covers) Heliotrope uses midnight, December 31, 1999 as a base reference date instead. This has the dual benefits of maintaining accuracy for current date calculations and shifting the decimal portion of the value so that it spans midnight to midnight rather from noon to noon, all designed to make life just a little easier for the user.

Watch here for more JDay manipulations to come!