Context: GNU ls -t means "sort by modification time" (no argument)

eza -t (short for --time FIELD) silently consumes the first positional argument as its field value when no explicit field is provided. Since it accepts any string without validation, it swallows a filename and exits 0 — no error, no warning. The file simply disappears from the output.

This is a significant footgun for anyone who aliases ls to eza. Scripts using ls -t *.md silently lose the first file in glob expansion order.

Reproduction

# Create 4 test files
mkdir /tmp/eza-test && cd /tmp/eza-test
touch a.md b.md c.md d.md

# GNU ls -t: 4 files (sorts by mtime)
/usr/bin/ls -t *.md | wc -l
# => 4

# eza -t: 3 files (first file consumed as FIELD argument)
eza -t *.md | wc -l
# => 3

# eza -t with explicit field: 4 files (correct)
eza -t modified *.md | wc -l
# => 4

# eza accepts ANY string as the field — no validation, no error
eza -t "totally-not-a-field" *.md
# => exits 0, shows 4 files (the nonsense field is silently ignored)

Expected behavior

At minimum, eza -t should validate the field argument and error on unrecognized values like filenames. Ideally:

1. Reject invalid field values with a clear error message (e.g., eza: invalid time field 'a.md', expected one of: modified, accessed, created)
2. Consider whether -t without an argument could default to modified for GNU ls compatibility, since alias ls=eza is a common pattern encouraged by eza's own documentation

Impact

Anyone with alias ls="eza ..." (a pattern eza encourages) who runs ls -t *.glob in a script will silently lose the first file. The failure mode is particularly dangerous because:

• Exit code is 0
• No warning or error on stderr
• Output looks plausible (N-1 files listed instead of N)
• The missing file changes based on glob expansion order, making it hard to notice

Environment

• eza v0.23.4 (also confirmed on v0.22.0)
• macOS 15 (Sequoia), ARM64
• Installed via Homebrew