arttime: terminal clocks, timers, and feed-driven ASCII art

arttime's terminal clock, alarm, and art workspace

arttime solves a specific problem for people who spend their working day in a terminal and do not want a conventional clock or productivity dashboard to take over that terminal. It combines three related jobs: displaying text art, measuring time, and accepting keyboard input. The intended users are developers, Unix users, and terminal-oriented people who want the Pomodoro method or a custom repeating schedule without moving to a separate desktop interface.

The art catalog is the project's most visible feature, with more than 500 ASCII, ANSI, PETSCII, and Unicode pieces listed in the README. Selection can be random, by name with completion hints, or through `fzf` when that optional program is installed. Art can also change every second, allowing two related images to form a simple animation. Each timer can have its own art, color, and message, so notification events can be visually distinguished instead of relying on identical clock screens.

The time-management model is broader than a single countdown. arttime accepts relative values such as `1h 30m` from the current moment and absolute values such as `Dec 22 2:45PM EST`. A session can contain multiple timers, repeat a pattern indefinitely or a fixed number of times, and display elapsed time, time remaining until the next timer, and time since the previous timer expired. Pressing `i` exposes all timers. The progress bar is text based and configurable, which fits the terminal display but does not provide the graphical controls users may expect from a dedicated productivity application.

A notable boundary appears in absolute schedules. The README says absolute goals such as `1PM` are also delayed when the complete time-management program is paused with `p`. It describes an override as a future capability rather than a currently documented setting. That behavior matters for anyone using arttime as an alarm, because suspension changes the schedule rather than preserving a strict wall-clock deadline.

Feed-driven input turns arttime into a display

arttime is designed around Unix-style input composition. Instead of limiting commands to the keyboard attached to the terminal, it can receive keystrokes from a file, pipe, string, or unrelated process. The README describes control returning cleanly to the keyboard when the input source ends. This is the application's most distinctive technical choice because it turns a timer into a programmable terminal display.

The documented data flow is straightforward: an external producer supplies key sequences, arttime consumes them as input, and the terminal continues with normal keyboard control after the source closes. The README says this can display system metrics, weather, stock market information, and other dynamic data through a feeder program. It also provides examples through the `k` menu, with the built-in manual available through `arttime -m`. The documentation points to the project wiki for more portable pipe syntax, which is important because shell quoting and pipe behavior can vary between systems.

This feature changes the project's scope. arttime is not only a timer with a visual theme. It is an input-driven terminal interface that can be placed behind another process and controlled without a human pressing every key. That makes it plausible for scripts, scheduled jobs, or small personal displays, although the README does not document a stable external API, a machine-readable event format, or a formal protocol for feeder programs.

The limitation is equally important. Feeder input is still key input, so an external process must know the prompts, modes, and key bindings that arttime expects. A malformed sequence can send an unintended command, and a process that fails partway through may leave the interaction in an unexpected state. The README documents the capability and examples, but it does not promise validation or recovery for arbitrary input streams.

History, notifications, suspension, and platform constraints

arttime treats terminal interaction as a persistent workspace rather than a disposable command. The README says prompts store up to 1,000 unique previous values, and users can retrieve them with the Up and Down arrow keys. It also retains history for the last 1,000 timers and time-management programs. Completion hints, globbing, and search are listed as related input features, while storyboards allow a sequence of art pieces to be assembled quickly.

Notifications are described as native desktop notifications, with the notification identifying the arttime instance that produced it. This is useful when several terminal sessions exist, but the README does not describe the exact notification backends or fallback behavior for every listed platform. Likewise, it mentions native sounds, without specifying sound-file formats or configuration commands. Those details should be checked on the target system before relying on notifications for a strict alarm.

Suspension is another deliberate design point. Pressing `Ctrl-z` suspends arttime, and `fg` resumes it. The README says the application does not occupy the terminal screen or consume power while suspended and still shows correct elapsed time after continuation. This makes it more compatible with shell work than a foreground dashboard would be. It also means that the timer state is tied to process continuation rather than necessarily representing a wall-clock alarm service.

The documented platform range is macOS, Linux, BSD Unixes, and Windows WSL. macOS support is described as working out of the box without Homebrew or developer tools, while other Unixes require `zsh`. The repository also contains a `Containerfile`, and the README has a Docker-oriented installation section, but the README excerpt does not include enough command text to reproduce a Docker invocation here. The top-level `install.sh` file indicates an installation script exists, but the README does not specify its options or exact invocation.

Installing arttime and beginning a timer session

The README identifies `install.sh` as part of the repository and includes an installation section, but the README does not show the exact installation command, permissions, or configuration steps. It also mentions trying arttime in Docker and points to the repository's `Containerfile`, but no Docker command is documented in the README excerpt. Because the documentation does not provide a reliable command line, there is no command block to reproduce here.

A first use should begin with the program's own help or manual once arttime has been made available according to the repository instructions. The README explicitly names `arttime -m` as the manual command and documents `k` as the entry point for preinstalled key-feed examples. It also states that `timer` and `story` can be entered at that prompt, with Tab completion available. The first practical session can therefore be built around those documented interactions rather than an invented flag.

To create a relative timer, the README gives the format `1h 30m` from the current time. To create an absolute timer, it gives `Dec 22 2:45PM EST`. After entering a timer or selecting a mode, the user can press `i` to inspect all timers and `p` to pause or delay a running time-management program. The visible result should be a text-art display with timer information and a configurable progress bar. Native notifications appear when a timer expires, subject to the platform's desktop notification support.

For a first feeder experiment, the documented route is to launch arttime in a mode where input can come from a file, pipe, string, or unrelated process, then use one of the examples available through `k`. The exact syntax is delegated to the wiki because the README specifically points there for portable pipe syntax. Do not assume that an arbitrary command can be piped into arttime without checking that syntax first.

Custom licenses and the actual maintenance signal

The repository is not marked as archived, and its last push was on 2026-08-18. The recent release history also includes v2.5.0 on 2026-08-17, v2.4.0 on 2025-07-27, and v2.3.4 on 2024-06-02. These dates establish recent project activity, but they do not tell you whether every platform or feeder example is currently supported. The README itself describes platform-specific behavior and compatibility changes, so updates should be assessed against the operating systems and workflows you need.

The licensing arrangement is unusually important here. The repository has separate files named `LICENSE`, `LICENSE_CODE`, `LICENSE_ART`, and `LICENSE_ADDENDUM_CFLA`. The repository metadata reports a custom license that GitHub cannot classify. That means the project cannot safely be described as using one standard license without reading those files. Code, art, and any additional terms may have different conditions, and the addendum may affect how the bundled material is used.

This is not legal advice, but it is a concrete adoption condition. A team that needs to redistribute arttime, modify the code, ship the art collection in another product, or combine the project with internal tooling should inspect all four license files and identify the terms that apply to each part. The README's statement that the application is human-readable and local does not substitute for those permissions and obligations.

Compared with a packaged clock or graphical productivity application, arttime has fewer installation assumptions and a more inspectable text-based implementation, but its custom license and platform-dependent shell behavior create their own review cost. The README claims no internet connection and no data sent outside the computer. It also says optional features rely on standard operating-system packages. Those are useful privacy characteristics, but feeder programs remain outside arttime's documented boundary.

Why arttime differs from a standard timer or display wrapper

A conventional timer usually centers on one countdown, a few buttons, and a graphical notification. arttime instead treats timing as a programmable terminal session. It supports multiple timers, repeating patterns, absolute and relative values, custom art per timer, history, completion, interactive time-zone switching, and input generated by other processes. That combination makes it closer to a terminal dashboard with an input stream than to a single-purpose alarm.

The real distinction is therefore not merely that arttime displays time. It combines scheduling semantics with a human-facing terminal application and accepts external keystrokes as a first-class input source.

The trade-off is complexity. A single countdown is easier to understand than a pattern-based time manager, especially when pause behavior can delay absolute goals and feeder syntax depends on terminal conventions. For a user who needs strict wall-clock scheduling, a system scheduler may provide a clearer model. For a user who wants a personal terminal workspace, arttime offers capabilities that a basic scheduler and a static ASCII image do not cover.

arttime is also not a replacement for a dedicated system monitor, stock feed, or weather service. Its README presents those as possible outputs produced by external feeder programs. The application is the terminal framework around that data, not the data source itself.

Editorial conclusion

arttime fits terminal-focused users who want configurable time management, local operation, and text art in the same interface. It is a poor fit for users who need a documented graphical installer, a standard open source license, or predictable behavior from opaque feeder programs. Before adoption, verify the `LICENSE`, `LICENSE_CODE`, `LICENSE_ART`, and `LICENSE_ADDENDUM_CFLA` files, inspect the shell entry points under `bin/`, and confirm that your Unix environment provides `zsh` unless it is macOS.

Frequently asked questions

Official sources

1. Issues
2. poetaman/arttime on GitHub
3. README
4. Releases