Introduction

A MySQL DATETIME value often reaches JavaScript as a string such as 2025-09-23 14:30:00. Converting that safely is not just a formatting problem. You also need a timezone policy, because MySQL DATETIME does not store timezone information while JavaScript Date represents a specific moment in time.

Understand What the MySQL Value Means

A MySQL DATETIME stores calendar date and time without timezone metadata. That means a string like 2025-09-23 14:30:00 is ambiguous until your application decides whether it represents:

• UTC,
• server local time,
• user local time,
• some other agreed application timezone.

If you skip that decision and let JavaScript guess, behavior can vary across environments.

Convert as UTC Explicitly

If your application treats database datetimes as UTC, convert them into an ISO-style string with T and Z.

1function mysqlDatetimeToUtcDate(mysqlValue) {
2  const iso = mysqlValue.replace(" ", "T") + "Z";
3  return new Date(iso);
4}
5
6const d = mysqlDatetimeToUtcDate("2025-09-23 14:30:00");
7console.log(d.toISOString());

This is a good approach when the backend stores UTC values consistently and the frontend should interpret them the same way.

Convert as Local Time Intentionally

If the string should be interpreted as local time, parse the components yourself and construct the Date explicitly.

1function mysqlDatetimeToLocalDate(mysqlValue) {
2  const [datePart, timePart] = mysqlValue.split(" ");
3  const [y, m, d] = datePart.split("-").map(Number);
4  const [hh, mm, ss] = timePart.split(":").map(Number);
5  return new Date(y, m - 1, d, hh, mm, ss);
6}
7
8const local = mysqlDatetimeToLocalDate("2025-09-23 14:30:00");
9console.log(local.toString());

Manual parsing avoids relying on the less predictable behavior of new Date("YYYY-MM-DD HH:mm:ss").

Validate the Input Before Converting

If the value may be null, empty, or malformed, validate before parsing.

1function safeMysqlDatetimeToUtcDate(mysqlValue) {
2  if (!mysqlValue || typeof mysqlValue !== "string") {
3    return null;
4  }
5
6  const iso = mysqlValue.replace(" ", "T") + "Z";
7  const date = new Date(iso);
8  return Number.isNaN(date.getTime()) ? null : date;
9}

Returning null for bad input is often safer than letting invalid dates flow deeper into the UI.

Format for Display After Conversion

Once you have a valid Date, use formatting APIs for display.

1const formatter = new Intl.DateTimeFormat("en-CA", {
2  dateStyle: "medium",
3  timeStyle: "short",
4  timeZone: "America/Toronto",
5});
6
7console.log(formatter.format(new Date("2025-09-23T14:30:00Z")));

This keeps conversion logic separate from user-facing formatting logic.

Driver and Backend Behavior Matter Too

In Node.js, some MySQL drivers can return date-like fields as strings or already-converted values depending on configuration. If timezone correctness matters, keep that driver behavior explicit and consistent.

More broadly, if you control the schema or backend contract, ask whether the application should standardize on UTC before the value ever reaches JavaScript. Many frontend date-conversion bugs are really backend ambiguity bugs. It is also worth adding tests around daylight-saving transitions if the application interprets database values as local time, because those are exactly the cases where hidden assumptions surface.

Common Pitfalls

A common mistake is calling new Date("YYYY-MM-DD HH:mm:ss") and assuming identical behavior everywhere. That string format is not the safest cross-environment contract.

Another issue is forgetting that MySQL DATETIME itself has no timezone information.

Developers also often mix UTC interpretation in one part of the application with local-time interpretation in another, which creates subtle inconsistencies.

Summary

• A MySQL DATETIME string needs an explicit timezone interpretation before safe JavaScript conversion.
• If the value is UTC, convert it into an ISO-style string with T and Z.
• If the value is local time, parse the parts manually and construct the Date directly.
• Validate uncertain input before converting it into a Date.
• Keep one consistent date-conversion policy across the whole application.