Lines Matching refs:timestamps
110 correction is zero for all timestamps; otherwise, for timestamps
135 timestamps past 2037, so users desiring (say) Greek time should instead
138 and older timestamps need not be handled accurately.
178 of a leap second; timestamps after this expiration are unreliable in
181 timestamps are treated.
202 readers about timestamps within the contiguous sub-sequence. It also
207 readers should either refuse to process post-expiration timestamps, or
249 limit glitches to rarely used timestamps and allow simple partial
260 even if the reader's native timestamps have only 32 bits.
262 * Some readers designed for version 2 might mishandle timestamps after
266 that only far-future timestamps are mishandled by version 2 readers.
282 * Some readers ignore the footer, and instead predict future timestamps
286 * Some readers do not use time type 0 for timestamps before the first
291 * Some readers mishandle timestamps before the first transition that
293 32-bit timestamps are likely to be more prone to this problem, for
326 * Some readers generate ambiguous timestamps for positive leap seconds
339 * Some readers do not support negative timestamps. Developers of
343 * Some readers mishandle timestamps before the first transition that
345 timestamps are likely to be more prone to this problem.