Timegaps is a cross-platform command line program. It sorts a set of items into
rejected and accepted ones, based on the age of each item and user-given
time categorization rules.
Timegaps is built with a focus on reliability. It is backed by a considerable
set of unit tests, including direct command line interface tests. Currently,
each commit is automatically tested
against CPython 2.7/3.3/3.4 on Linux via Travis CI. Releases are tested on Linux
as well as on Windows. Simplicity and compliance with the Unix philosophy are the major design goals of
timegaps. Version tags follow the concept of semantic versioning.
Consider the following situation: all *.tar.gz files in the current working
directory happen to be daily snapshots of something. The task is to accept one
snapshot for each of the last 20 days, one for each for the last 8 weeks, and
one for each of the last 12 months, and to reject all others. Use timegaps for
performing this categorization into rejected and accepted items and print the
$ timegaps days20,weeks8,months12 *.tar.gz | sort
This was a read-only, non-invasive operation. By default, timegaps prints the
rejected items to stdout, separated by newline characters (for compatibility
with other Unix command line tools). Repeat the operation and count the rejected
$ timegaps days20,weeks8,months12 *.tar.gz | wc -l
Given this specific set of rules and set of items, timegaps identified 125 items
to be rejected. Move them to the directory notneededanymore (and suppress
$ mkdir notneededanymore
$ timegaps --move notneededanymore days20,weeks8,months12 *.tar.gz > /dev/null
Count files in the newly created directory for validation purposes (must also be
$ /bin/ls -1 notneededanymore/* | wc -l
Okay, so far the item modification time was determined from the inode via the
stat() system call. In a different mode of operation (--time-from-
basename), timegaps can read the “modification time” from the basename. The
file names of the tarred snapshots in this hands-on session carry meaningful
time information, in a certain format (daily-%Y-%m-%d-%H%M%S.tar.gz).
Providing this format string, we can instruct timegaps to parse the time from
these file names:
$ mv notneededanymore/* .
$ timegaps --time-from-basename daily-%Y-%m-%d-%H%M%S.tar.gz \
days20,weeks8,months12 *.tar.gz | wc -l
The above can be useful in cases where the actual file modification time is
screwed, and the real timing information is only contained in the file name. In
another mode of operation (--stdin), timegaps can read newline-separated
items from stdin, instead of reading items from the command line:
$ /bin/ls -1 *tar.gz | timegaps --stdin days20,weeks8,months12 | wc -l
Given -0/--nullsep, timegaps can handle NUL character-separated items on
stdin. In this mode of operation, timegaps also NUL-separates the items on
$ find . -name "*tar.gz" -print0 | \
timegaps -0 --stdin days20,weeks8,months12 | \
tr '\0' '\n' | wc -l
By default, the reference time for determining the age of items is the time of
program invocation. Use -t/--reference-time for changing the reference time
from now to an arbitrary date (January 1st, 2020 in this case):
$ timegaps --reference-time 20200101-000000 years10 *.tar.gz | wc -l
With a different reference time and different rules the number of rejected items
obviously changed (from 125 to 153). Instead of printing the rejected items,
timegaps can invert the output and print the accepted ones:
$ timegaps -a -t 20200101-000000 years10 *.tar.gz
There are more features, such as deleting files, or a mode in which items are
treated as simple strings instead of paths. See the help message:
$ timegaps --help
usage: timegaps [-h] [--extended-help] [--version] [-s] [-0] [-a] [-t TIME]
[--time-from-basename FMT | --time-from-string FMT]
[-d | -m DIR] [-r] [-v]
RULES [ITEM [ITEM ...]]
Accept or reject items based on age categorization.
RULES A string defining the categorization rules. Must be of
the form <category><maxcount>[,<category><maxcount>[,
... ]]. Example: 'recent5,days12,months5'. Valid
<category> values: years, months, weeks, days, hours,
recent. Valid <maxcount> values: positive integers.
Default maxcount for unspecified categories: 0.
ITEM Treated as path to file system entry (default) or as
string (--time-from-string mode). Must be omitted in
--stdin mode. Warning: duplicate items are treated
-h, --help Show help message and exit.
--extended-help Show extended help message and exit.
--version Show version information and exit.
-s, --stdin Read items from stdin. The default separator is one
-0, --nullsep Input and output item separator is NUL character
instead of newline character.
-a, --accepted Output accepted items and perform actions on accepted
items. Overrides default, which is to output rejected
items (and act on them).
-t TIME, --reference-time TIME
Parse reference time from local time string TIME.
Required format is YYYYmmDD-HHMMSS. Overrides default
reference time, which is the time of program
Parse item modification time from the item path
basename, according to format string FMT (cf. Python's
strptime() docs at bit.ly/strptime). This overrides
the default behavior, which is to extract the
modification time from the inode.
Treat items as strings (do not validate paths). Parse
time from item string using format string FMT (cf.
-d, --delete Attempt to delete rejected paths.
-m DIR, --move DIR Attempt to move rejected paths to directory DIR.
Enable deletion of non-empty directories.
-v, --verbose Control verbosity. Can be specified multiple times for
increasing verbosity level. Levels: error (default),
For a detailed specification of program behavior and the time categorization
method, please confer timegaps --extended-help.
The well-established backup solution rsnapshot
has the useful concept of hourly / daily / weekly / ... snapshots already
built in and creates such a structure on the fly. Unfortunately, other backup
approaches often lack such a fine-grained backup retention logic, and people
tend to hack simple filters themselves. Furthermore, even rsnapshot is not able
to post-process and thin out an existing set of snapshots. This is where
timegaps comes in: you can use the backup solution of your choice for
periodically (e.g. hourly) creating a snapshot. You can then — independently
and at any time — process this set of snapshots with timegaps and identify
those snapshots that need to be eliminated (removed or displaced) in order to
maintain a certain “logarithmic” distribution of snapshots in time. This is the
main motivation behind timegaps, but of course you can use it for filtering any
kind of time-dependent data.