• Home
Name Date Size #Lines LOC

..--

README.mdD04-Jul-20252.2 KiB3431

clock.ccD04-Jul-2025241 124

clock.hD04-Jul-20251.1 KiB4112

default_clock.ccD04-Jul-2025488 2412

default_clock.hD04-Jul-2025714 2914

default_tick_clock.ccD04-Jul-2025564 2412

default_tick_clock.hD04-Jul-20251.1 KiB3313

pr_time_unittest.ccD04-Jul-20259.8 KiB289224

tick_clock.ccD04-Jul-2025254 124

tick_clock.hD04-Jul-20251.5 KiB4612

time.ccD04-Jul-202511.3 KiB326209

time.hD04-Jul-202557 KiB1,432709

time_android.ccD04-Jul-20252.4 KiB6617

time_apple.mmD04-Jul-20257 KiB215175

time_apple_unittest.mmD04-Jul-20256.3 KiB179141

time_conversion_posix.ccD04-Jul-20251.9 KiB6852

time_delta_from_string.ccD04-Jul-20255.4 KiB162101

time_delta_from_string.hD04-Jul-20251.3 KiB4011

time_delta_from_string_fuzzer.ccD04-Jul-2025477 1810

time_delta_from_string_unittest.ccD04-Jul-20254.7 KiB11075

time_exploded_icu.ccD04-Jul-20255.9 KiB162110

time_exploded_posix.ccD04-Jul-20259.8 KiB300205

time_fuchsia.ccD04-Jul-20252.6 KiB10367

time_fuzzer.ccD04-Jul-20251.7 KiB5438

time_now_posix.ccD04-Jul-20254.4 KiB151102

time_override.ccD04-Jul-20252.2 KiB6149

time_override.hD04-Jul-20254.4 KiB10351

time_unittest.ccD04-Jul-2025100.6 KiB2,6801,967

time_win.ccD04-Jul-202531.3 KiB835434

time_win_perftest.ccD04-Jul-20255.1 KiB14299

time_win_unittest.ccD04-Jul-202515.2 KiB457284

README.md

1# //base: Time-Related Functionality
2
3This directory contains the portions of //base that deal with time-related
4concepts. Most critical are the classes in [time.h](time.h).
5 - `Time` represents a specific wall-clock time. It is computed from the system
6clock, meaning successive requests for the current time might not always
7monotonically increase (e.g. across automatic or manual clock adjustments).
8Generally it is appropriate for anything human-visible, e.g. the last modified
9date/time of a file or a future time when Chrome will be automatically
10restarted, but users must safely handle negative durations and other effects of
11the non-monotonic clock.
12 - `TimeTicks` is computed from an incrementing counter. It thus increases
13monotonically, meaning it's usually appropriate for determining how much time
14elapses between two nearby events, e.g. for function timing for profiling, or to
15schedule a task "100 milliseconds from now", regardless of what the clock reads
16at that point. However, its behavior across power-saving mode changes is
17platform-dependent, meaning it may not increment during times when the system
18clock continues to run, and the precise conditions under which it does increment
19vary by platform. This usually makes it inappropriate for long durations,
20especially in cross-platform code; for example, a histogram that uses
21`TimeTicks` to count events in a thirty-day window will show very different
22results on a platform that pauses the counter during sleep compared to one where
23it continues to run. It is also non-sensical to try and convert a `TimeTicks` to
24a `Time` and then use that as a reference point for any other `TimeTicks` value,
25since even within the same process, both intervening sleeps and intervening
26clock adjustments may mean the values should have had different reference points.
27 - `TimeDelta` represents a duration between two Times or TimeTicks.
28
29There are also various files dealing with clocks, which are primarily useful
30when tests need to modify how the program tracks the passage of time. See
31[/base/test/task_environment.h](/base/test/task_environment.h)'s `MOCK_TIME`
32ability for
33[testing components which post tasks](/docs/threading_and_tasks_testing.md).
34