The Same Climate Time Coordinates Can Name Different Dates

Read the axis before selecting a month

A climate-model input can carry the same three numerical time coordinates in two files while assigning them different date labels. A downstream request for February then concerns the declared calendar, not just a range of array positions. That matters when a scientific-AI workflow selects seasonal inputs, joins date-labelled targets or compares exports from separate simulations.

This explanation uses the historical CF 1.12 conventions, dated December 4, 2024. Section 4.4 relates a time coordinate to its datetime through the units and calendar. The units supply a time measure and reference datetime. The calendar supplies the permitted datetimes and their order. Those roles remain relevant when the data is delivered outside the original NetCDF file.

The existing packed-NetCDF guide follows codes, missingness and scale/offset into interpreted measurements. Here the payload values are held fixed. The question is which date the time position denotes, and consequently which positions a date-labelled request selects.

References: [CF-T]

A fixed day length leaves different month boundaries

CF 1.12 uses fixed time units: a day is 86,400 seconds. Its 360_day calendar has twelve months of 30 days each. Its proleptic_gregorian calendar extends the Gregorian leap-year rules across its date range. Equal elapsed-day coordinates therefore need not carry equal month/day labels.

A month used as a duration unit is another distinction. CF follows UDUNITS in defining that unit as one twelfth of its fixed year unit, rather than as a calendar month. The conventions recommend avoiding year and month units because of the potential confusion. CAL-59 below uses days throughout, so no variable-length month duration is hidden in its arithmetic.

Leap-second interpretation also needs a declared basis. For the example's proleptic_gregorian model, units_metadata is explicitly leap_seconds: none: leap seconds do not exist in that model timeline. This keyword is not attached to 360_day. CF permits the leap_seconds keyword only with standard, proleptic_gregorian or julian calendars; 360_day already excludes leap seconds. These are supplied interpretation premises, not instructions to change an actual dataset.

References: [CF-T][CF-C][CF-L]

CAL-59: three positions, two date interpretations

Consider two fictional model inputs, A and B. Each has time units days since 2001-01-01 00:00:00 and the ordered coordinates 58, 59 and 60. Each coordinate is associated with the same stipulated payload position in the two inputs. A declares calendar 360_day. B declares calendar proleptic_gregorian and the no-leap-second model premise above. No file or reader was executed for this comparison.

Coordinate zero denotes the stated January 1 reference. In A, January occupies offsets 0 through 29. February starts at offset 30 and occupies offsets 30 through 59. Offset 58 is therefore February 29, offset 59 is February 30 and offset 60 is March 1.

In B, 2001 is not a Gregorian leap year. January occupies offsets 0 through 30; February begins at 31 and ends at 58. The same offsets consequently identify February 28, March 1 and March 2. Every datetime in the table is midnight under its declared model interpretation.

References: [CF-C]

February contains two supplied positions in A and one in B

Now give the consumer one precise request: select the supplied positions whose declared model date lies in February 2001. Within this three-position subset, A returns coordinates 58 and 59. B returns coordinate 58 alone. The counts are two and one. They are not the total number of February samples in either complete model dataset.

A's coordinate 59 belongs to February because its date is February 30 in 360_day. Calling that label an invalid Gregorian date would apply B's calendar to A. Dropping it on that basis would remove a valid supplied model position from A's requested February population. Conversely, treating B's coordinate 59 as February would include its March 1 position.

The two axes still have equal numbers, equal units strings and equal array lengths. Those properties cannot settle month membership. Position-by-position pairing can preserve numerical order while pairing different date labels. Date-label matching presents a different question again: A's March 1 is at coordinate 60, while B's is at 59. Neither pairing rule can be inferred solely from the matching word time.

The useful result is the explicit membership explanation. It does not establish that these separate model dates correspond to the same physical instant, that their payloads describe comparable conditions or that either population is scientifically preferable.

Compare an axis-preserving export with a relabelled one

Suppose a supplier offers A's three payload positions for a seasonal AI input. Offer Axis retains their ordered coordinates and complete applicable time interpretation. Its proposed consumer can explain why 58 and 59 belong to February and why 60 does not. That answers CAL-59's selection question without requiring Gregorian labels.

Offer Relabel retains the same payloads and coordinates but presents Gregorian dates without supplying a scientifically agreed transformation. It assigns February 28, March 1 and March 2. Its February selection now contains only the first position. Saying that all original payload bytes survived would leave the changed date-selection meaning unexplained.

An export supplying decoded labels can also be useful if it preserves A's actual calendar and the association between each label and payload. A label such as 2001-02-30 needs its declared calendar available to the receiving representation and consumer. A recipient that accepts only Gregorian dates cannot be assumed to preserve this meaning merely because it accepts the file format.

Have the appointed data provider trace the intended date request through the actual offered export and consumer. For CAL-59, the return should identify the interpretation used and the selected payload positions, then reconcile the two-versus-one difference. File metadata at an earlier stage does not establish what the recipient ultimately receives. Choose the deliverable that preserves the requested interpretation, rather than awarding completeness to whichever output has familiar-looking dates.

Calendar interpretation comes before scientific alignment

Understanding A's February population does not define how to compare it with B's February. The calendars have different valid date sets. Matching labels, matching coordinate offsets and constructing a scientifically justified common timeline are different operations. CF's calendar definitions explain the distinction without selecting a transformation for a particular model task.

The example supplies no rule for deleting extra dates, stretching 360 days into 365, interpolating payloads or choosing seasonal weights. Those choices can change the input population and relationships that a model learns. The appointed scientific and application owners need to state the comparison they require and substantiate any transformation separately. A successful date decode also supplies no forecast-quality or source-clock-accuracy result.

The related PostgreSQL timestamp article handles explicit offsets, retained instants and original zone context. That is a different representation problem. Converting a zone offset cannot make A's February 30 a Gregorian date while preserving the same calendar meaning. Use the packed-NetCDF guide for value transformation and missingness, alongside this time-axis interpretation, when both are present in one delivered input.

References: [CF-C]

Scope a separate equipment installation when needed

If the wider scientific-AI project also needs customer-selected equipment installed, Leviathan's Rack-and-Stack Installation service provides a route to discuss agreed mounting, physical IT connections, labels and installation records. The related project inquiry can carry a nonconfidential equipment list, released rack plan, approved connection requirements and desired work window into that scope discussion.

That is a separate physical project. Calendar transformation, scientific interpretation, reader compatibility and AI software delivery remain with the appointed data and software providers.