The JWST onboard clock functionality and performance is described in this article.

Summary

The primary clock onboard JWST is within the spacecraft bus. That onboard clock is quantized to count in units of 64 milliseconds, so the onboard time-keeping for the absolute time of events such as exposure start times does not support finer precision than that. That clock is regularly synchronized with UTC on the ground to compensate for clock drifts. The resulting achieved absolute timing accuracy is about 100 milliseconds (typical), up to 230 milliseconds (worst case, driven by time between JWST contacts).

This clock source is used to timestamp spacecraft engineering telemetry and is distributed to the science instrument computer (ICDH), and ultimately is the source of timing information in science data files. Science users should typically expect ~100 millisecond clock accuracy in science data files, though some outlier datasets may at times slightly exceed that.

Note that this is a statement about absolute accuracy of timestamps relative to UTC only; the relative precision of e.g., pixel clocking rates or subarray frame times does not depend on UTC time, and such relative time measurements are generally much more precise. The ICDH computer and the various instrument readout electronics track time more finely to microsecond precision for timing and control of detector readouts (but these clocks are not synchronized to UTC with microsecond accuracy). 

Spacecraft clock operations and performance

The spacecraft clock is driven by a high accuracy oscillator in the Command and Telemetry Processor (CTP), the main spacecraft computer on JWST. The clock is managed by the spacecraft Flight Software (FSW) and increments in 64 ms ticks, once per FSW minor cycle. 

The clock performance is driven by the requirement to remain calibrated to within ±2 s of UTC for a period of 40 hours without intervention; regular ground commanding for clock drifts results in accuracy much better than ± 2 s. 

Spacecraft clock drift

The time indicated by the spacecraft clock drifts away from UTC due to small oscillator inaccuracies. This clock drift is monitored and trended by the JWST Flight Operations Team. An onboard drift bias correction factor, configured in integer units of μs/1.024 s, can be used to automatically correct for drift by periodically making small adjustments to the time. Using the drift bias correction, the clock drift can be maintained within ±1 μs/1.024 s.  Any drift magnitude smaller than 1 μs/1.024 s cannot be automatically corrected onboard.

As of early 2026, the mean measured clock drift is approximately +0.5 μs/1.024 s, and has been stable since the start of JWST science operations. As this measured drift is less than 1 μs/1.024 s there is no further onboard drift correction that can be applied; accumulated clock error must be periodically corrected using ground commanded clock adjustments. 

Spacecraft clock correlation

A clock offset measurement occurs every 32 seconds while the observatory is in contact with the ground. The offset between the spacecraft clock and UTC time is measured using the Return Data-Delay (RDD) method with the light time delay and known hardware delays subtracted out. Due to the FSW minor cycle duration there is ambiguity in the clock offset measurement, resulting in an error of up to +64 ms. 

A procedure is executed at the beginning of each observatory contact to sample the clock offset and, if needed, command a clock adjustment. Multiple samples of the measured clock offset are taken, and a clock adjustment is commanded if the mean of these samples is >64 ms. The adjustment is performed slowly, at a rate of 1 ms/1.024 s, to avoid large clock discontinuities. As of early 2026, a clock adjustment is typically commanded once every 1.5 days.

Given the JWST contact schedule, there are typically 2–3 opportunities per day to execute a clock adjustment. However, there can be periods of limited contact availability, and it is possible to go multiple days without clock offset measurement and adjustment.

Resulting spacecraft clock accuracy

The clock accuracy is driven by the drift rate and the time between executions of the clock adjustment procedure.

In a typical scenario:

• Clock drift of 0.5 μs/1.024 s (i.e., drift rate as measured)
• 12 hours between contacts
• Clock accuracy: 64 ms (maximum uncorrected value) + 21 ms (maximum drift between contacts) = 85 ms overall accuracy

In a worst-case scenario:

• Clock drift of 1 μs/1.024 s
• 48 hours between contacts
• Clock accuracy: 64 ms (maximum uncorrected value) + 168 ms (maximum drift between contacts) = 232 ms clock accuracy

Note: there may be rare events when the time between JWST contacts exceeds 48 hours. This would further reduce the clock accuracy.

Clock offset telemetry

The measured clock offset from UTC can be retrieved from the MAST JWST Calibrated Engineering Data Portal. This can, in principle, be used to correct and compensate for the ~0.1 s typical clock offsets, though this is not done automatically. 

• Mnemonic: FGDP_SCTA_OFFSET_D
• Unit: μs

A positive value indicates that the spacecraft clock is ahead of UTC. This telemetry is only calculated when the observatory is in contact with the ground; gaps in the data are expected. 

This derived telemetry includes occasional outliers that are caused by ground system misconfiguration and observatory mode changes. Discard data points with a magnitude >0.5 s and/or a trend inconsistent with the previous observatory contact. These outlying samples do not accurately represent the clock offset.

Over the 4-year period 2022 June 1 to 2026 June 1, and excluding the occasional outlier data points, the measured FGDP_SCTA_OFFSET_D values range from -98 to +99 milliseconds, with an average of 0.2 ms and a standard deviation of 44 ms. This illustrates the clock correction process working as intended. 

Instrument clock operations and science file time stamps

Instrument clock operations

The clock signal from the spacecraft computer is distributed once every 1.024 s to JWST's Instrument Command and Data Handling (ICDH) computer (the main instrument computer for the Integrated Science Instrument Module, ISIM) to synchronize the ISIM clock with the primary spacecraft clock. The ISIM clock is used for timing visit execution as well as time stamping ISIM science data and engineering telemetry. Because of the 64 ms quantization of the spacecraft clock, the ISIM clock will be within 64 ms accuracy to ground time. Internally the ICDH maintains a finer time count measured in microseconds (i.e., it has microsecond precision, but not microsecond accuracy). 

To understand how science data time keywords are set in detail, it is relevant that the pixel data in recorded science data files are saved as a packet stream, in effect an accumulation of data values throughout a series of up-the-ramp readouts. Each packet has a recorded time stamp set using the ISIM clock. The time stamp applied to the science data may vary slightly from actual end of the readout time due to delays in the transfer of the readout data from the detector through the ISIM to the Solid State Recorder. This delay depends on the ISIM data volume, but is on the order of up to ~10 milliseconds. 

The sum of the accuracies in the SC clock relative to UTC, ISIM clock relative to SC clock, and packet timestamp relative to exposure end time results in a overall timing accuracy of typically about 100–150 milliseconds. 

Independent external analyses using calibration data on sky find a measured clock accuracy that is consistent with this bottom-up engineering estimate. (Shaw et al. 2025).  

Science time in FITS headers

The fundamental time-related keywords in FITS data are generated by the Science Data Processing (SDP) software, a part of the JWST Data Management System that is responsible for stage 0 processing, the initial stage in which raw telemetry and science data packets downlinked from the spacecraft are used to produce the "uncal.fits" files that are used for later stages of pipeline processing. See JWST ETC Time Definitions for descriptions of the various keywords and their meanings; this article only provides information on how those keywords are populated. 

• DATE-END is populated based on the last frame stop time from the last header packet for all datasets in a given exposure. In effect, the DATE-END keyword is the most fundamental timestamp on any JWST exposure, and most other timing keywords are derived relative to it. EXPEND and MJD-END are set to the same value as DATE-END expressed as a modified Julian Date.  MJD in this context is specifically MJD in the UTC timescale. 
• DURATION is set to the total exposure duration, which is computed based on relevant exposure parameters (NINTS, NGROUPS, etc.) and the frame time TFRAME of the selected subarray or full frame readout mode. The frame time TFRAME is looked up from a Project Reference Database table of subarrays. Thus, the value of DURATION is computed independently of UTC timestamps. 
• DATE-BEG is set as DATE-END minus DURATION. And similarly EXPSTART and MJD-BEG give the same value expressed as MJD. 
• Note that most timestamp-related keywords are explicitly rounded to milliseconds when written to FITS headers. This includes DURATION, TELAPSE, EFFEXPTM, XPOSURE, EFFINTTM, TGROUP, TMEASURE, etc. Internally the Project Reference Database provides more significant figures for TFRAME, from which DURATION etc., are derived. TFRAME is written to headers without rounding but the other keywords are rounded to milliseconds. 

The GROUP and INT_TIMES extensions

For exposures with multiple integrations, in particular TSO observations, additional FITS extensions provide per-integration timings. The underlying mechanism is the same, based on the header packet timestamps of the recorded pixel data, applied to the packets for each individual group. In this case, for measuring the relative times of groups within a given exposure, the software is able to make use of microsecond time stamps in the header packets, so the relative timings here are not limited by the 64 ms quantized absolute accuracy of the UTC clock onboard. 

An additional factor here is that for subarray data, typically multiple subarray reads fit into a single image data packet. (The size of it is based on a set of memory buffers within JWST that are large enough to contain full frame reads. Multiple subarray reads can fit within a buffer large enough for a single full frame read). That means that header packets only provide timestamps every Nth read. For instance, it may be the case that 6 subarray frames fit within one packet, so there would be header packet timestamps for frames 6, 12, 18, and so on. These timestamps are available in the GROUP extension attached to UNCAL files, and will typically be discontiguous for TSO data using subarrays. Furthermore, the number of frames in a packet may not be the same as the number of groups in an integration, so these group readout times do not necessarily map directly to the end groups of each integration. 

To provide a complete set of integration start and end times for all integrations, a linear model is used to interpolate between the available subset of group integration times using a continuous running count of frame numbers throughout a given exposure. This is used to derive the end times of each integration, as best as possible from the subset of directly-available group times. For each integration, a start time, mid time, and end time are computed. These values are written to a table in the INT_TIMES FITS extension.  

Conversion to barycentric time

Additional keywords give those times converted from local UTC to the Solar System’s barycenter and on the Barycentric Dynamical Time standard (abbreviated TDB, from the French Temps Dynamique Barycentrique).

This relies on observatory ephemeris data generated by NASA's Flight Dynamics Facility group at Goddard. They evaluate the ephemeris and release an update weekly that includes the actual ephemeris up to a specific date, and a predicted ephemeris that is used for planning and executing upcoming observations. Initial science data processing immediately after observations are taken typically uses the predicted ephemeris for JWST's orbital motion that week, while subsequent reprocessing at later times will typically use the actual as-measured ephemeris for past dates. The difference between the predicted and as-measured ephemeris is typically negligible relative to other sources of timing uncertainty. 

• The barycentric correction is computed throughout each exposure. The correction at the start of the exposure is recorded in the keyword BARTDELT in the SCI extension header.
• The TDB-BEG, TDB-MID, TDB-END keywords are populated based on MJD-BEG, MJD-MID, MJD-END plus the barycentric correction.  
• For multi-integration data, the INT_TIMES extension includes the derived start, mid, and end times per each integration converted into barycentric time.  
• As of mid 2026, SDP does not write the TDB-* keywords for observations of moving targets within the Solar System. It is planned for a near-future upcoming release of SDP to address this so that the TDB-* keywords will be consistently present for all JWST data files, including retrospectively for earlier files once those datasets are reprocessed.

The algorithms used for UTC to BJD TDB were previously implemented as part of the JWST pipeline. The current implementation instead has that calculation happen within SDP, in stage 0 processing, but records of the previous versions are still available via Github as a reference for the algorithm implementation.  

For historical reasons, SDP also writes another copy of these values to additional keywords in the SCI extension header, labeled as BSTRTIME, BMIDTIME, BENDTIME. In practice, the values of these additional keywords may differ from the TDB-*  keywords by a negligible amount (less than a microsecond) due to floating point roundoff.

Comparison with recorded engineering telemetry time stamps

Engineering telemetry on JWST can be accessed via the JWST Calibrated Engineering Data Portal in MAST.  Note that telemetry time stamps recorded there are based on the spacecraft clock in UTC time. Thus, those timestamps should be in alignment with FITS header timestamps in UTC, within the 64 ms precision of the SC to ISIM clock synchronization, but comparison to TDB times requires applying a barycentric correction. The FITS keyword BARTDELT provides the correction value at the start of a given exposure, which can be applied to engineering telemetry timestamps in UTC to get barycentric times, via barycentric_time = utc_time + BARTDELT. 

References

Shaw, A. W., et al. 2025, AJ, 169, 21
Calibrating the Clock of JWST
(The results of General Observer calibration program 1666 that studied JWST clock accuracy were published in this paper.)