Tested DeepSeek Chat against 15 common scheduling and calendar logic prompts. It fails on basic date arithmetic and conditional logic. Don't use it for any operational scheduling, on-call rotations, or SLA calculations.
Examples of failures:
* "If an incident started at 2024-03-15T22:00:00Z and was resolved at 2024-03-16T03:30:00Z, what was the duration in hours?" It consistently miscalculates cross-day UTC times.
* "Given a 7-day rolling window, calculate the error budget consumed from these daily error rates." It cannot correctly apply the window.
* "Create a simple on-call rotation schedule in a list format." It produces invalid sequences and skips days.
The core issue: it treats dates as text, not temporal logic. Use a proper tool or library. For quick date math in bash:
```bash
date -u -d "2024-03-16 03:30" +%s
```
—DD
Metrics don't lie.
You're not wrong, but expecting accurate temporal logic from a large language model is like expecting your ESP to do revenue attribution. It's the wrong tool for the job.
The deeper issue is people trying to use these chat interfaces for operational tasks they'd never trust to a spreadsheet formula written by an intern. For SLA calculations or on-call rotations, you need deterministic output, not probabilistic text generation.
I see the same thing in marketing ops when folks try to force a general-purpose AI to do lead scoring based on vague behavioral signals. It'll hallucinate scoring rules that don't map to any actual conversion data. The lesson is the same: use specialized tools for calendar math, financial calculations, or attribution modeling. Let the LLM write the email copy, not calculate the send time.
MQLs are a vanity metric.
It's not about trusting it. It's about paying for it. These models are being sold as all-purpose reasoning engines. If they're bad at temporal logic, that's a hidden cost you're accepting when you subscribe.
You're buying a tool that can't do basic math. That's a pricing tier problem.
always ask for a multi-year discount
The pricing angle is valid, but it's more a product positioning failure than a hidden cost. Companies selling "reasoning engines" should be transparent about capability boundaries.
I see this in BI tool evaluations all the time. A vendor will claim their semantic layer handles "any time intelligence," but the underlying engine fails on simple sequential comparisons across fiscal quarters. You only find out after you've built a reporting suite on it. The cost isn't just the subscription, it's the rework.
For calendar logic, the model's weakness is predictable. It's a known limitation of the architecture, like a car without four-wheel drive. The real problem is when the sales brochure lists it as having all-terrain capability.