In Google Forms, use a Date question for a calendar date and a Time question for a clock time or duration. Date questions have options for including the year or time. Time questions can distinguish a time of day from elapsed time.
The most important choice comes before the field type: what does the answer mean? “Preferred visit date,” “Date the problem first occurred,” and “How long the task took” need different instructions, even when they appear in the same form.
A date entered into a form is information supplied by the participant. It is not automatically a confirmed appointment, an available slot, or the deadline for submitting the form.
Last verified: September 22, 2026
Decide whether you need a date, clock time, or duration
A date identifies a day. A clock time identifies a point within a day. A duration describes how much time elapsed. Start with that distinction rather than choosing whichever control looks easiest to add.
| Information you need | Example answer in ordinary language | Suitable starting point |
|---|---|---|
| When an event happened | September 22, 2026 | Date |
| When someone would prefer a visit | October 6, 2026 | Date, with request wording |
| When a task started | 2:30 in the afternoon on the stated date | Clock time with date context |
| How long a task lasted | One hour and twenty minutes | Duration |
| An annual month-and-day reference | April 12, without a year | Date configuration after checking the purpose |
These are illustrative values, not available appointments or recommendations for a particular schedule. Name the meaning in the question label so an exported answer remains understandable later.
For example, replace “Date” with “Date you first noticed the issue.” Replace “Time” with “Approximate time the issue began.” If the participant may not know the exact answer, explain how to indicate uncertainty rather than encouraging a made-up value.
Add the question and inspect its options
Google's question-type help describes date options for including a year or time through the question's More menu. It also describes switching a time question between clock time and duration. Google's date and time question help
The Forms API separately represents the date settings as includeYear and includeTime, and the time distinction through duration. This confirms that a calendar date, an added clock time, and elapsed time are different configuration decisions. Google Forms API DateQuestion and TimeQuestion
Choose the type that fits your answer, then check the displayed options rather than relying on an older screenshot. Add a description where the field label alone cannot explain the intended value.
After setup, read the question as a participant. If the label says “How long did it take?” but the control looks like a time-of-day input, revisit the configuration. An example in the description can help, but it should not be used to compensate for the wrong type.
For the broader creation process, the Google Forms setup guide covers the steps beyond this particular field choice.
Include the year when the record needs it
A year is essential when records may refer to different years or need to be understood later. Incident dates, visit requests, and event records usually need a complete date to avoid ambiguity.
An annual reminder might only need a month and day, but do not omit the year merely to make the question shorter. First decide whether the missing information would change how the answer is used.
Imagine a coordinator reviewing requests in January. An answer showing only “December 20” could refer to a past event or a future preference. The form's surrounding explanation may have been obvious when the participant answered, but the exported record needs enough context to remain useful.
A practical question-review note could say: “Include the year because staff compare requests across calendar years.” That makes the design decision easier to maintain when someone copies the form for the next cycle.
Avoid collecting a full birth date when the task only needs an annual month-and-day reference. Match the detail requested to the actual purpose instead of assuming every date question should collect the same information.
Explain the time basis
A clock time such as 14:30 needs context when people may be in different places. State whose local time applies or identify the relevant time zone in the question or description.
For a local event, a label such as “Preferred start time, venue local time” may be clearer than an unexplained time field. For an international audience, provide an explicit convention and enough information to identify the event location or time basis.
Do not assume the input control automatically converts a participant's answer to the organizer's time zone. This article does not verify automatic conversion, device-locale formatting, or stored-response representation for every environment.
A copy example for a Japan-based workshop could be:
Preferred start time in Japan Standard Time. This is a request; the organizer will confirm the date and time separately.
If your task spans locations whose offsets change during the year, review the date and time basis together. The form should not require the participant to guess which seasonal offset the organizer intends. Use a clear scheduling process for that situation rather than an unlabeled clock time.
Example 1: collect a preferred visit date
Suppose an organizer wants two possible dates before contacting a participant. Use distinct labels such as “First preferred visit date” and “Second preferred visit date.” Make clear whether the second option is optional.
The introduction could say:
Tell us your preferred dates. We will check availability and contact you with a proposed appointment. Sending this form does not reserve a time.
Keep the answer structure aligned with the decision. If you need several candidates, use separately labeled candidate questions or a suitable list of specific choices. Do not imply that one date question automatically collects a ranked set of dates.
Before sharing, decide what staff should do when the first and second preferences match, when only one is provided, or when both fall outside the period you intended. Instructions, available choices, and review procedures should agree.
The Google Forms booking guide covers the larger reservation process. A date question can support that process, but it does not itself provide capacity management or booking confirmation.
Example 2: record when a problem occurred
For a support report, separate the date of the event from the date the person is filling out the form. “Date you first noticed the issue” expresses that difference more clearly than “Today's date.”
If time matters, explain whether an estimate is acceptable. Someone reporting an intermittent problem may know that it happened during the afternoon but not the exact minute. Requiring false precision can make a record appear more reliable than it is.
One design is to collect the date, make the precise time optional, and provide a short place to describe uncertainty. Whether that fits your process depends on what the support team actually needs.
Do not combine “When did it start?” and “How long did it last?” into one field. A start time and an elapsed duration answer different questions. The distinction becomes especially important when a problem begins on one day and continues into the next.
Example 3: collect elapsed time
For a training exercise, you may want to know how long a participant spent on a task. A duration question is more appropriate than asking for the clock time at which they finished.
State the measurement rule. For example: “Time spent on the practice task, excluding the break.” Without that explanation, one participant may report active work while another includes the entire session.
Choose the level of precision your decision needs. If approximate minutes are sufficient, do not imply that participants must reconstruct exact seconds. Conversely, if a timed exercise has a formal measurement procedure, give that procedure separately from the form control.
Use sample answers to test interpretation. “One hour and twenty minutes” should be understood as elapsed time, not 1:20 in the morning. The field label, selected mode, and helper text should all communicate the same meaning.
These examples are questionnaire-design suggestions, not measured task-performance results. Collecting a duration does not by itself establish productivity or explain why two participants took different amounts of time.
A date question is not a collection deadline
A deadline controls when the form accepts responses. A date question records an answer within a response. Adding a question labeled “Deadline” does not automatically close collection at that date.
If your goal is to stop accepting submissions, use the separate Google Forms deadline and response-limit guide. Keep the closing rule and the participant's requested date distinct in both your instructions and your records.
For example, a workshop may accept requests until one date while asking participants to choose a later visit date. Those two dates belong to different parts of the process. Calling both of them “registration date” can confuse staff as well as respondents.
Likewise, do not describe a requested future date as available merely because the form accepted the answer. Availability requires a separate check of the schedule and whatever constraints govern the event.
Test realistic cases and record the result
Create a short test plan before sharing. Use the exact configuration and instructions you intend to publish, including required status and any added time component.
| Case | What to verify |
|---|---|
| A normal complete date | The participant can enter the intended day and year |
| A date near the end of a year | The year remains unambiguous |
| An empty optional candidate | The intended optional path works |
| An empty required date | The participant receives understandable guidance |
| A date with a clock time | Both parts are clear and captured as intended |
| A duration example | It is interpreted as elapsed time rather than a clock reading |
| A phone used by the audience | The actual input interaction is usable |
The table contains checks to perform, not verified Google outcomes. Fill in observed results after testing. Include the device or browser context when a problem depends on the input interaction.
If you perform a submission test, inspect the resulting record and distinguish it from real requests. A successful on-screen entry does not establish that downstream staff will interpret the value correctly. Check the labels and context in the place where the response will be reviewed.
Do not assume identical pickers on every device
The way a date or time input appears is not the whole feature. A calendar picker, typed entry, and a mobile input interface may present different interaction questions that need testing with the intended audience.
Google's iPhone and iPad creation help includes a note about date and time picker support. That limited note should not be expanded into a claim that people can never answer date or time questions on an iPhone. Google Forms iPhone and iPad help
I have not tested the device combinations for this article. Use the participant-facing form on the devices you expect people to use, and describe any actual limitation narrowly. If an alternative answer route is necessary, explain it clearly rather than telling people to invent a placeholder date.
Also distinguish the displayed format from your intended meaning. An English help example does not establish that every locale displays month, day, and year in the same order. Clear labels and a realistic test reduce the chance of relying on an ambiguous numeric date.
FORMLOVA date settings have validation boundaries
FORMLOVA's current implementation has date, time, and combined date-time fields. The combined field can display a time selector and configured minimum and maximum dates in its date input.
Those display settings should not be described as a universal server-side date-range guarantee. The current combined date-time schema checks for a nonempty value when required; it does not establish all range conditions or guarantee that every requested time component is present.
That distinction matters when a date controls an important business decision. A user-interface limit is not a substitute for a verified rule governing accepted records. Review the actual submission behavior and your operational checks before promising that every out-of-range answer is rejected.
A starting request to an AI client connected to FORMLOVA could be:
Draft an unpublished visit-request form with first and optional second preferred dates. State the time basis if a time is requested. Explain that the appointment is not confirmed, and show me which restrictions are input guidance and which are validated before publication.
For the wider choice of collection and response-management tools, return to the Google Forms, Sheets, and Apps Script operations guide.
Disclosure and Verification
I develop FORMLOVA. I checked Google's question-type help, DateQuestion and TimeQuestion API definitions, iOS help, and FORMLOVA's date/time renderers and validator on September 22, 2026. I did not configure or submit a live Google date/time question while preparing this article. The examples are proposed wording and test cases, not available bookings. Device-specific picker behavior, locale display, and every stored-value format were not tested.
