How to structure date and time fields in your ChatGPT app
Of the 383 date and time parameters we found across more than 80 ChatGPT apps, 198 of them (52%) provide zero guidance on what format they expect: no example, no description, nothing at all.
That means when a user asks "find me rides available next Tuesday at 3pm," ChatGPT has to guess whether your API wants 2025-02-18, 02/18/2025, 1739894400, or something else entirely. And when it guesses wrong, your app returns an error.
We dug into the metadata of 147 third-party apps live in the ChatGPT App Store to understand how developers are handling date and time fields. Here's what we found.
The Format Landscape: What 383 Date/Time Parameters Look Like
Here's how those 383 date/time parameters break down by format specification:
| Format | Count | Share |
|---|---|---|
| Unspecified (no format guidance) | 198 | 52.0% |
| YYYY-MM-DD | 81 | 21.0% |
| ISO-8601 | 22 | 5.7% |
| Other specified format | 22 | 5.7% |
| Relative/Natural language | 20 | 5.2% |
| Duration | 17 | 4.4% |
| Timezone | 11 | 2.9% |
| Unix timestamp | 7 | 1.8% |
| MM/DD/YYYY | 5 | 1.3% |
The top-line number is hard to ignore: more than half of all date/time parameters leave ChatGPT to figure it out on its own. That might work sometimes (ChatGPT is pretty good at defaulting to YYYY-MM-DD), but "sometimes" isn't the reliability bar you want for a production app.
On the positive side, YYYY-MM-DD is the clear runner-up at 21%, making it the de facto standard when developers do specify a format. That aligns with what ChatGPT defaults to when it has to guess, which means developers who take the time to specify a format are overwhelmingly picking the one that plays nicest with the model. If you're going to specify any format (and you should), YYYY-MM-DD is the safest bet for date-only fields.
The other notable pattern is fragmentation. Even among apps that do specify a format, there's no consensus beyond that YYYY-MM-DD cluster. You've got ISO-8601, plain date strings, Unix timestamps, natural language, and duration formats all coexisting. That's not inherently bad, but it puts more pressure on your metadata to be clear about what your API expects.
It's also worth noting that the 52% unspecified rate, while lower than what we found in our initial broader analysis that included OpenAI's built-in integrations, still represents a significant gap. This is a systemic pattern rather than an edge case, and it's one that developers can fix with minimal effort. We think it represents one of the biggest opportunities for improving ChatGPT app reliability today.
The Most Date-Heavy Apps
Some apps lean on temporal data far more heavily than others. The three apps with the most date/time parameters in our dataset are:
| App | Date/Time Params |
|---|---|
| Monday.com | 23 |
| S&P Global | 21 |
| Airtable | 18 |
This makes intuitive sense. Monday.com is a project management tool where nearly everything (tasks, milestones, sprints, deadlines) lives on a timeline. S&P Global delivers financial data that's inherently time-series in nature: stock prices, earnings dates, economic indicators all indexed by date. And Airtable, as a flexible database, lets users define their own date fields across every table they build.
These apps face the date/time format challenge at scale. When you have 20+ parameters that touch dates and times, the cost of ambiguity compounds. A single missing format description might cause an occasional error, but 20 missing descriptions across a deeply temporal app create a lot of surface area for things to go wrong. If you're building an app where temporal data is core to the functionality, getting your date/time metadata right matters a lot.
Apps That Do It Well
The best apps don't just name a format; they describe it, give examples, and explain why it matters.
Uber stands out. Their timezone parameter includes this metadata:
"IANA timezone format (example: America/New_York) for accurate time calculations. Determine based on pickup or drop-off location"
This works well for three reasons: it names the format (IANA), provides a concrete example (America/New_York), and tells the model how to determine the right value based on context. ChatGPT doesn't have to guess, because it knows exactly what to pass and where to get the information.
Apps using ISO-8601 with clear descriptions also perform well. When a parameter description says something like "Start date in ISO-8601 format (e.g., 2025-01-15T09:00:00Z)," the model has everything it needs to construct a valid value. The example eliminates ambiguity about whether you want just a date, a date with time, or a date with time and timezone offset.
The pattern across well-structured apps is consistent: format name + example + context. All three pieces matter.
Apps That Do It Poorly
On the other end of the spectrum, some apps provide almost nothing.
Datadog has multiple time-related parameters (from_time, to_time, start_time, end_time) where the description is NULL, with no format, no example, and no hint about whether these should be ISO timestamps, Unix epochs, or relative strings like "1 hour ago." ChatGPT has to infer everything from the parameter name alone.
Box and Dropbox both use a parameter called recency_days with no description. It's unclear whether it expects an integer or a string, or whether 7 means "the last 7 days" or "7 days from now." The parameter name suggests recency, but without a description, the model is left to make assumptions about both the format and the semantics.
With 52% of date/time parameters having no format guidance at all, these aren't edge cases. Every time ChatGPT guesses wrong, users see an error or, worse, get silently incorrect results.
Recommended Metadata Patterns for Each Format Type
Based on what we've seen working well, here are metadata patterns we'd recommend for the most common date/time formats:
Date strings (YYYY-MM-DD)
"Date in YYYY-MM-DD format (e.g., 2025-02-16). Use the current date as reference for relative requests like 'tomorrow' or 'next week'."
ISO-8601 datetime
"Datetime in ISO-8601 format (e.g., 2025-02-16T14:30:00Z). Always include timezone offset. Default to UTC if user timezone is unknown."
Unix timestamp
"Unix timestamp in seconds (e.g., 1739712000 for 2025-02-16T12:00:00Z). Must be a positive integer."
Timezone
"IANA timezone identifier (e.g., America/New_York, Europe/London). Determine based on user location or context."
Duration
"Duration in ISO-8601 format (e.g., PT1H30M for 1 hour 30 minutes, P7D for 7 days)."
Relative/Natural language
"Relative time expression (e.g., '1 hour ago', 'last 7 days'). Supports natural language time references."
The pattern across all of these: every recommendation includes the format name, a concrete example, and behavioral guidance for the model. The example does most of the heavy lifting. Models are very good at pattern-matching from examples, so even a single well-chosen example can significantly reduce format errors.
Why This Matters: The Cost of Ambiguity
When ChatGPT doesn't know what format a date/time field expects, it defaults to its best guess. That guess is usually YYYY-MM-DD for dates and ISO-8601 for datetimes, which is reasonable. But "reasonable" breaks down quickly in practice.
Consider a flight search app that expects departure times as Unix timestamps. ChatGPT, lacking any format guidance, sends 2025-02-18T09:00:00Z. The API rejects it, the user sees an error message (or a vague "something went wrong"), they try again with the same result, and they leave.
Multiply that across 198 parameters with no format guidance, serving millions of ChatGPT users, and the aggregate cost in failed requests, user frustration, and abandoned sessions adds up.
The fix is simple and takes about 30 seconds per parameter: add a description with the format name and an example. You don't need to restructure your API or change your schema, just tell the model what you expect.
Methodology
This analysis covers 147 third-party apps in the ChatGPT App Store as of February 2025. We excluded integrations built and maintained by OpenAI (like GitHub, Linear, Slack, and Google Workspace) to focus on apps that companies built and shipped independently. Of those 147 apps, more than 80 contained at least one date/time-related parameter, totaling 383 parameters analyzed. Parameters were categorized by format type based on their name, description, and any examples or constraints provided in the metadata.
What Should You Do Next?
If you're building or maintaining a ChatGPT App, it's worth auditing your date/time parameters. Open your app's server config, find every parameter that touches dates, times, durations, or timezones, and ask yourself whether ChatGPT would know exactly what format to send based on the metadata alone. If not, add a description with a format name and example.
We're also actively researching broader questions, like how format specification correlates with app error rates and whether apps with better metadata get suggested more often by ChatGPT.
Want access to the full dataset? Contact us to learn more.