Date to Unix Timestamp
Date to Unix Timestamp converts a selected date and time into elapsed whole seconds since the Unix epoch. A datetime-local input has no written timezone, so the browser interprets it in the device's local zone before deriving the UTC-based instant. The result therefore depends on the active timezone and daylight-saving rules.
Runs locally — files stay on your deviceDoes a datetime-local value contain a timezone?
No. The browser supplies the device's local timezone when interpreting it.
Unix timestamps represent instants, not displayed timezones
Unix time counts seconds from 1970-01-01 00:00:00 UTC. Local wall-clock input must first be mapped to an instant using timezone rules.
How it works
Choose a local date and time. The browser parses it in the current local timezone, converts to milliseconds since the epoch, and returns whole seconds.
Key concepts
Local interpretation comes first
The same wall-clock text can yield different timestamps in different timezones.
The output is in seconds
Some JavaScript APIs instead expect milliseconds.
When to use it
- Prepare a common epoch value for an API.
- Translate a local scheduled time to Unix seconds.
- Compare the reverse timestamp conversion.
When not to use it
- Do not assume the input is UTC.
- Do not use an ambiguous daylight-saving time without confirming its offset.
- Do not expect the timestamp to retain a timezone name.
Worked examples
Unix epoch in UTC
- Input
1970-01-01 00:00 in UTC- Expected output
0
This is the epoch origin.
Same instant, different display
- Input
Equivalent local times in two zones- Expected output
Same timestamp
Unix time identifies the instant.
Seconds versus milliseconds
- Input
A returned 10-digit modern value- Expected output
Unix seconds
Multiply by 1000 only for APIs requiring milliseconds.
Common mistakes
Reading local input as UTC
datetime-local has no zone marker. Correction: Confirm the browser timezone before converting.
Sending seconds to a milliseconds API
The factor-of-1000 mismatch gives a wrong date. Correction: Check the receiving API's unit.
Expecting timezone recovery
An epoch value does not encode a zone name. Correction: Store timezone metadata separately when needed.
Best practices
- Record the intended timezone beside scheduled wall time.
- Confirm seconds versus milliseconds.
- Test ambiguous and skipped daylight-saving times.
Related operations and differences
Unix Timestamp to Date
Choose Unix Timestamp to Date when you need to convert Unix seconds or milliseconds to ISO time.; use Date to Unix Timestamp specifically for date to unix.
Add Days to Date
Choose Add Days to Date when you need to find a future date after adding days.; use Date to Unix Timestamp specifically for date to unix.
Add Months to Date
Choose Add Months to Date when you need to add calendar months using local browser time.; use Date to Unix Timestamp specifically for date to unix.
Add Weeks to Date
Choose Add Weeks to Date when you need to add a number of weeks to a date.; use Date to Unix Timestamp specifically for date to unix.
Age Calculator
Choose Age Calculator when you need to calculate age in completed years.; use Date to Unix Timestamp specifically for date to unix.
Business Days Calculator
Choose Business Days Calculator when you need to count weekdays between two dates.; use Date to Unix Timestamp specifically for date to unix.
Limitations and privacy
- Input uses the browser's local timezone.
- The result does not retain timezone identity.
- Ambiguous daylight-saving times are resolved by browser behavior.
Dates and calculations stay in this browser and are not uploaded.
Frequently asked questions
Is the output seconds or milliseconds?
Seconds.
What timezone is the input?
The browser's local timezone.
Does a Unix timestamp store a timezone?
No.
Can daylight-saving time affect the result?
Yes, because local wall time is mapped through timezone rules.