dateutils gives the shell date commands the standard tools never had

Ten small programs that behave like the shell tools you already use

Dateutils is described as a bunch of tools that revolve around fiddling with dates and times on the command line, with a strong focus on use cases that arise when dealing with large amounts of financial data. The design decision that makes them easy to adopt is the naming. Every command is prefixed with date, and otherwise resembles a known Unix command for reasons of intuition, so dateseq mirrors seq, datetest mirrors test, and dategrep mirrors grep. The one exception is strptime, which is the command line version of the C function of the same name. The full set is strptime, dateadd, dateconv, datediff, dategrep, dateround, dateseq, datesort, datetest and datezone. That is ten small executables rather than one tool with many modes, and the practical effect is that each one has a narrow job, its own manual page, and a predictable place in a pipeline. The README states the aim plainly, that everything is explained by example to get a first impression, and points to the info and man pages for the full specifications, with installation instructions in a separate file in the repository.

dateseq replaces the shell loop you keep rewriting

The first example in the README is a script any engineer has written at least once, a loop over seq computing a date per iteration.

$ for i in $(seq 0 9); do
    date -d "2010-01-01 +${i} days" "+%F"
  done

The replacement takes both ends of the range directly, and the end date can be given rather than computed.

$ dateseq 2010-01-01 2010-01-10

The extra feature is the one that makes it worth installing. A range can skip particular weekdays, which the README describes as painful to implement with the seq and date approach.

$ dateseq 2010-01-01 2010-01-10 --skip sat,sun

It also works on times and on date-times rather than only on calendar dates, and there is a compute-from-last mode that aligns the generated sequence to the end of the range instead of the start. For a script that needs every working day in a quarter, or every hour slot in a schedule, this is the difference between three lines of shell and a wrapper program.

dateconv handles the representations finance actually uses

Most conversion tools focus on turning Gregorian dates into another calendar, and the README says dateconv aims instead at the calendric systems that are essential in financial contexts. The example is the year, month, calendar week and weekday representation, which encodes the nth occurrence of a weekday in a month, useful when a date is specified as the third Thursday in May.

$ dateconv 2012-03-04 -f "%Y-%m-%c-%w"
  2012-03-01-00

And back again.

$ dateconv 2012-03-01-Sun -i "%Y-%m-%c-%a" -f '%F'
  2012-03-04

The tool also converts occurrences inside a stream rather than a single value, rewriting dates embedded in text as they pass through, and it converts between time zones in bulk, with a from-zone and a zone option, either for a literal timestamp or for the current time. That last form is the one that shows up in scripts, where a log line or a report has to be rendered in the reader's timezone rather than the server's.

Arithmetic that knows about leap seconds

dateadd performs date arithmetic and datediff is its converse, and between them they cover the operations a script needs. Adding a duration to a date, in days, weeks, hours or minutes, works in the obvious way, and it applies to a list of dates read from standard input as well as to a single value. The interesting capability is the leap second handling. A unit of rs denotes real seconds, so adding thirty of them to the last half minute of June 2012 lands on the leap second itself rather than skipping past it.

$ dateadd '2012-06-30 23:59:30' +30rs
  2012-06-30T23:59:60

The same difference shows up in the other direction, where the format specifier for real seconds asks datediff for the elapsed time in real seconds rather than in nominal ones, giving sixty one seconds across a leap second boundary where the arithmetic of ordinary seconds would give sixty. The README notes that these adjusted calculations can be made if the system's zoneinfo database supports it, which is the practical dependency to check before you rely on the behaviour.

The rest of the set covers filtering, comparison, rounding and zones

The remaining commands fill the gaps that a shell script keeps running into. datetest performs date comparison and is modelled after the test command but with proper command line options, so a shell conditional reads as a comparison rather than as a string comparison on formatted output. dategrep extracts lines from an input stream that match criteria, showing either the whole line or just the match, which is how you pull out the interesting rows of a dated log. dateround rounds a date or timestamp to a recurring point in time, like the next or previous January, or the next or previous Thursday, and it works in both directions, which is what you need to find the period a record belongs to. datesort sorts chronologically, and datezone converts dates and times to timezones in bulk rather than one at a time. Put together, the set covers the pipeline shapes that recur: generate a range, filter a stream, sort the results, compare against a boundary and convert for presentation.

Autotools, three CI systems and a slow release cadence

The build system is the classic GNU autotools one, with a configure script generated from configure.ac, a Makefile.am, a version file template, a build-aux directory for the auxiliary scripts and an m4 directory for the macros. The tree also holds the lib and src directories, the test directory, an info directory for the documentation sources, a data directory, a contrib directory and a GNUmakefile at the top level. The project is mirrored across several forges in a way that says something about its age, with the primary hosting on GitHub, a project homepage on the author's own site, downloads hosted on Bitbucket, and CI configuration for Travis, GitLab and Drone, plus a Coverity scan badge. The release history is irregular, with 0.4.10 in May 2022, 0.4.11 in January 2024 and 0.4.12 in September 2026, and the last push was on 2026-09-24. A gap of two and a half years between two tags is worth weighing if you plan to depend on a specific version, since the readme's examples reflect whichever release you read. The licence is a custom one that GitHub cannot classify, so the LICENSE file is the document to read before you redistribute it.

Editorial conclusion

dateutils suits anyone writing shell scripts over financial or business dated data, since week and month based date representations, calendar conversion and leap second handling are exactly the cases where the standard date command and a loop over seq fall apart, and the tools are small enough to install beside anything else. It is the wrong choice if all you need is formatting a timestamp, since the coreutils date already does that, and it is the wrong choice if you want a library rather than programs, because there is no library interface in the repository, only executables. Verify three things before you build a pipeline on it: that the version you install is recent enough for the features you need, since the release history has long gaps between 0.4.10 and 0.4.12, that your system's zoneinfo database carries leap second data, since the real seconds calculations depend on it, and that the output format you parse is stable, because the readme documents the switches as examples rather than as a specification. The licence is in the LICENSE file, the last push was on 2026-09-24, and the project is hosted on GitHub with a separate project page and downloads on Bitbucket.

Frequently asked questions

Official sources

1. hroptatyr/dateutils on GitHub
2. Issues
3. Project website
4. README
5. Releases