NetCDF Time Axes — Epochs, Units and Calendars (.nc)
Three CF time coordinates over the same six records: hours from the Unix epoch, days from 2026-01-01, and the same days under a 365_day calendar. A decoder that assumes one epoch, or ignores the calendar attribute, dates the records wrongly without raising anything.
| Variable | Units | Calendar | First value | Decodes to |
|---|---|---|---|---|
| time | hours since 1970-01-01 00:00:00 | proleptic_gregorian | 490896 | 2026-01-01T00:00:00Z |
| time_days | days since 2026-01-01 00:00:00 | proleptic_gregorian | 0.0 | 2026-01-01T00:00:00Z |
| time_noleap | days since 2026-01-01 00:00:00 | 365_day | 0.0 | 2026-01-01 (no-leap calendar) |
| pressure | Pa | - | 101325.0 | one standard atmosphere |
Specifications
- Records
- 6
- Time Variables
- 3
- Units
- hours since 1970-01-01; days since 2026-01-01
- Calendars
- proleptic_gregorian, 365_day
- Data Variable
- pressure (Pa)
Testing contract
Expected to pass- Scenario
- Decode each time coordinate to real timestamps using its own units and calendar attributes.
- Expected result
- All three resolve to 2026-01-01T00:00:00Z onward at six-hour steps — 490896 hours from the Unix epoch is the same instant as day 0 of 2026 — and time_noleap reaches those civil dates under a no-leap calendar.
What is a .nc file?
NetCDF (.nc, Network Common Data Form) is a binary, self-describing format for array-oriented scientific data. It stores multidimensional variables (like temperature over latitude, longitude, and time) with named dimensions, units, and metadata attributes, and is a standard in climate, ocean, and geoscience.
How to use this file
Use an example .nc file to test NetCDF readers (netCDF4, xarray, Panoply), CF-convention validators, and gridded-data pipelines, or to verify dimension and variable extraction.
How to use this file for testing
“NetCDF Time Axes — Epochs, Units and Calendars (.nc)” is a deterministic Novus Examples fixture for Scientific data, Serialization testing. Citation catalogs (BibTeX, RIS), chemistry structures (MDL Molfile, PDB), and gridded binary data (NetCDF, FITS) — for testing reference managers, molecule viewers, and scientific-data loaders.
Documented properties for this file: 6 records. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Scientific fixtures are small, valid, and fully synthetic — no real organism, patient, sample, or observation. Point your parser or loader at the file and check it reads the documented records, variables, or headers; binary formats ship a readable twin or metadata listing for comparison.
Related files
- ncNetCDF 64-bit Offset Format — CDF-2 (.nc)The same 4x5x6 temperature grid written in the 64-bit offset variant of NetCDF-3, whose only visible difference from the classic file is the fourth magic byte and the width of the header offsets. Use it to check that format sniffing looks at the version byte instead of stopping at the 'CDF' signature.
- ncNetCDF CF-1.8 Gridded Air Temperature (.nc)A NetCDF-3 classic file holding a 4x5x6 air-temperature field with full CF-1.8 coordinate metadata: standard names, axis attributes, units on every variable, and a declared _FillValue. Use it to check that a reader attaches units and coordinates to the array rather than returning bare numbers.
- ncNetCDF Packed int16 with scale_factor / add_offset (.nc)The same temperature field stored as int16 and recovered through the CF packing attributes scale_factor and add_offset. This is the failure that parses cleanly and is silently wrong: a reader that ignores the attributes returns values around -2000 instead of 260-292 K.
- binDICOM-Shaped Part 10 File — Explicit VR, Synthetic Phantom (.bin)A DICOM Part 10 file built byte by byte: 128-byte preamble, the DICM magic, an explicit-VR file meta group and a 27-element dataset ending in 16-bit pixel data. Every identifier is invented: the patient name is SYNTHETIC^PHANTOM, the instance UIDs sit under the unregistered 2.25 UUID arc, and the pixels are a generated pattern. There is no protected health information here and nothing in the file refers to a real person, device or study.
- binDICOM-Shaped Part 10 File — Implicit VR, Synthetic Phantom (.bin)The same synthetic phantom written with the implicit-VR transfer syntax, where element types never appear on the wire and a reader must consult a data dictionary to know that Rows is a 16-bit integer. The file meta group stays explicit VR, which is the mixed-mode detail parsers most often miss. Every identifier is invented: the patient name is SYNTHETIC^PHANTOM, the instance UIDs sit under the unregistered 2.25 UUID arc, and the pixels are a generated pattern. There is no protected health information here and nothing in the file refers to a real person, device or study.
- binDICOM-Shaped Stream — No Preamble, No DICM Magic (.bin)The identical element stream with the 128-byte preamble and the DICM magic stripped, which is how DICOM often arrives out of a network transfer or a database blob column. It is not a conformant Part 10 file and its content is entirely recoverable, so a reader should fall back rather than reject.
Generated by generation/scientific.py. Free for any use, no attribution required — license.