# Bad value “datetime” for attribute “type” on element “input”.

> Canonical HTML version: https://rocketvalidator.com/html-validation/bad-value-datetime-for-attribute-type-on-element-input
> Attribution: Rocket Validator (https://rocketvalidator.com)
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

The `datetime` input type was originally proposed to allow users to enter a date and time along with a timezone. However, no browser ever fully implemented it with a usable UI, and the WHATWG HTML Living Standard officially dropped it. Because `datetime` is not a recognized value for the `type` attribute, browsers treat `<input type="datetime">` as `<input type="text">` — a plain text field with no built-in date or time validation, no native picker, and no semantic meaning for assistive technologies.

This matters for several reasons. From an **accessibility** standpoint, screen readers and other assistive technologies rely on the correct `type` attribute to communicate the purpose of an input to users. A fallback to `type="text"` provides no such context. From a **validation and user experience** perspective, native date/time input types offer built-in pickers on mobile and desktop browsers, enforce format constraints, and support attributes like `min`, `max`, and `step` — none of which work correctly when the type falls back to plain text. From a **standards compliance** perspective, using an obsolete type means your HTML is invalid, which can cause issues with automated testing, SEO audits, and quality assurance processes.

## How to Fix It

Choose a replacement based on what data you need to collect:

- **`type="datetime-local"`** — Collects both a date and a time without timezone information. This is the most direct replacement for the old `datetime` type.
- **`type="date"`** — Collects only a date (year, month, day).
- **`type="time"`** — Collects only a time (hours, minutes, optionally seconds).
- **`type="text"` with a JavaScript widget** — Use this approach if you need timezone-aware datetime input, since no native HTML input type currently handles timezones.

The `datetime-local` input supports useful attributes like `min`, `max`, `step`, `value`, and `name`, giving you control over the range and granularity of selectable values. The `step` attribute is specified in seconds (e.g., `step="60"` for one-minute intervals, `step="1"` to allow seconds).

## Examples

### ❌ Invalid: Using the obsolete `datetime` type

This triggers the W3C validation error:

```html
<form>
  <label>
    Meeting:
    <input type="datetime" name="meeting">
  </label>
</form>
```

### ✅ Fixed: Using `datetime-local`

Replace `datetime` with `datetime-local` to collect both a date and time:

```html
<form>
  <label>
    Meeting:
    <input type="datetime-local" name="meeting" step="60">
  </label>
</form>
```

### ✅ Fixed: Using separate `date` and `time` inputs

If you prefer to collect the date and time independently, split them into two fields:

```html
<form>
  <label>
    Meeting date:
    <input type="date" name="meeting-date" min="2025-01-01" max="2025-12-31">
  </label>
  <label>
    Meeting time:
    <input type="time" name="meeting-time" step="900">
  </label>
</form>
```

In this example, `step="900"` on the time input sets 15-minute intervals (900 seconds).

### ✅ Fixed: Using `datetime-local` with constraints

You can set minimum and maximum allowed values using the standard datetime-local format (`YYYY-MM-DDThh:mm`):

```html
<form>
  <label>
    Appointment:
    <input
      type="datetime-local"
      name="appointment"
      min="2025-06-01T09:00"
      max="2025-06-30T17:00"
      step="1800"
      required>
  </label>
  <button type="submit">Book</button>
</form>
```

This restricts selection to June 2025 during business hours, in 30-minute increments, and makes the field required.