Showing julianDates as typical date/time strings

Hi guys,

What’s the recommended way to display a JulianDate?

Most of our example code looks like this:

julianDate.toDate().toUTCString();

The conversion to native JavaScript dates means we don’t display leap seconds correctly (you’ll see midnight of July 1, 2012 repeated as two adjacent seconds on the timeline demo, the first of which actually represents a leap second from the end of the previous day).

      --Ed.

Longer term we can have several functions and/or overloads that do what we need depending on the use case. Or maybe toString can take a format string that provides the user with a lot of control for how exactly to format the date.

If we wanted to get really fancy, we could introduce a GregorianDate type which would mirror Date’s API but would actually work properly to account for leap seconds and have better precision. Then the user could make his own string just by calling get Year/Month/Day/Hour/Minute/Second methods on GregorianDate.

Obviously these are just my opinions, so what do you guys think?

The GregorianDate in STK Components was designed to mirror the .NET DateTime class. If we make a similar class in JavaScript, I agree it should mirror the JavaScript Date class, except allow for 61 seconds in a minute. High precision of fractional seconds is less important, but it’s not really difficult to achieve just by storing values in multiple fields instead of the naive millis since the epoch approach. Format strings can be a lot of work, so since Date doesn’t provide any, I think we can skip that for now.

After reading Scott’s post, I think I’m leaning towards the GregorianDate approach and let users create their own string from that (which should be easy for their specific use cases).

It also occurred to me that a prototype toString for JulianDate should probably not do formatting and instead just print it’s components (which are useful for debugging).

So I think the answer to your original question is “Let’s add a GregorianDate object that makes it easy to get specific Year/Month/Day/House/Minute/Second information from a JulianDate and properly accounts for leap seconds and sub-millisecond times. This allows users to easily retrieve information they need to format exactly to their specific use case”.

Matt

We already have a method to parse an ISO8601 string directly to a JulianDate, so why not have a method to go the other way? IMO, everyone should be using ISO8601 anyway, especially on the web where taking into account the date formatting in different cultures is both important and a hassle.

A function to convert to ISO8601 would solve my immediate need, and since we can construct JulianDates from ISO8601 it makes a lot of sense for this to be bi-directional. We should offer an option to control the number of digits of precision: The other project I’m working on has a requirement to store and display dates that have been recorded out to 6 digits (one-millionth of a second), and our Cesium Timeline can zoom-in to display 3 digits (one-thousandth of a second increments, which was an arbitrary decision on my part that I’m re-thinking now in light of the other project). Some third-party apps can only parse ISO8601 when it’s rounded to the nearest whole second. Can numDigits or similar be a parameter of the JulianDate.toISO8601() function?

On a slightly different topic, when we’re inside a leap second, why do we round up? For the leap second at the end of June, when converted to a native JavaScript date, we report it as a duplicate of midnight the first second of July. This means the day, the month, and even the day-of-week are all incorrect during that second (as seen from native dates that can report day-of-week etc). Why not round down instead of up, and have a duplicate of June 30 23:59:59? (Then I could just steal the seconds off the end of the ISO8601 converted string, and use native dates for everything else, including localized month names etc.)

       --Ed.

I think two parameters (one for precision and one indicating local or UTC time) are a good idea. Since I did the fromIso work, I’ll take a stab at the toIso function, unless someone else is eager to do it.

As for the rounding, I believe this is what Components does as well, which is why we went with it. Your line of reasoning is sound though, so maybe we can change it. Kevin, what are your thoughts on the rounding?