On Feb 7, 2011, at 10:34 AM, Stephen Fisher wrote:
> On Mon, Feb 07, 2011 at 07:52:30AM -0500, Matthew Parris wrote:
>
>>> Within the abs_time_to_str function, 1900 is added to the tm_year
>>> parameter, but 1 is not added to the tm_yday. I'm used to seeing
>>> the day of the year equal to 1 on January 1st. Does anyone use 0
>>> for January 1?
>
> I agree that changing it to "1" for Jan 1 makes sense from a human
> reading the screen perspective.
The "day of year" format code was introduced to support a couple of CCSDS:
http://en.wikipedia.org/wiki/Consultative_Committee_for_Space_Data_Systems
protocols. The code it replaced displayed the day-of-year as 0-origin; however, this document:
http://public.ccsds.org/publications/archive/301x0b2s.pdf
speaks of day-of-year as being 1-origin, at least for the ASCII time code formats.
Unless the NASA guys who contributed the packet-ccsds.c and packet-vcdu.c dissectors would like to argue that, in their dissection, a 0-origin day-of-year works better, in which case we should support both 0-origin and 1-origin display formats, I would suggest switching to a 1-origin display format and see whether we get a complaint from any space data people (in which case we should add a separate 0-origin format).
