---
id: sql-dates
title: "SQL Dates"
category: "Database"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["SQL Working With Dates", "SQL 날짜"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.88
created_at: 2026-07-04
updated_at: 2026-07-04
review_reason: ""
merge_history: []
tags: ["sql", "database", "w3schools", "dates"]
raw_sources: ["https://www.w3schools.com/sql/sql_dates.asp"]
applied_in: []
github_commit: ""
---

# [[SQL Dates]]

## 🎯 한 줄 통찰 (One-line insight)
Matching a date literal against a datetime column silently returns nothing if the stored value carries a time component the literal doesn't — the hardest part of SQL dates is format alignment, not date logic itself. [S1]

## 🧠 핵심 개념 (Core concepts)
- **The core difficulty** — being sure the date format you insert/select matches the database column's format. [S1]
- **MySQL date types** — `DATE` (YYYY-MM-DD), `DATETIME`/`TIMESTAMP` (YYYY-MM-DD HH:MI:SS), `TIME` (HH:MI:SS), `YEAR` (YYYY or YY). [S1]
- **SQL Server date types** — `DATE`, `DATETIME`, `SMALLDATETIME`, `TIME`, `TIMESTAMP` (a unique number, not a date). [S1]

## 🧩 추출된 패턴 (Extracted patterns)
- **Time-component footgun** — a WHERE clause like `OrderDate='2025-11-11'` matches rows when the column is pure `DATE`, but silently returns zero rows once the column stores a time component too (e.g. `2025-11-11 13:23:44`), because exact string/value equality no longer holds. [S1]
- **Keep dates time-free unless necessary** — the source explicitly recommends avoiding time-components in date columns to keep queries simple, unless the time is actually needed. [S1]

## 📖 세부 내용 (Details)
- Simple date match (works, no time component): `SELECT * FROM Orders WHERE OrderDate='2025-11-11'`. [S1]
- Same query against a column that also stores time (returns NO rows, since exact match requires the time portion too): same query, different schema. [S1]

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
소스에서 모순되는 정보는 발견되지 않음. 다만 "동일해 보이는 쿼리가 스키마에 따라 결과가 완전히 달라진다"는 점이 핵심 경고로 제시됨. [S1]

## 🛠️ 적용 사례 (Applied in summary)
현재 발견된 실제 적용 사례가 없습니다 — "쿼리가 아무 결과도 안 준다"는 흔한 버그의 원인이 날짜/시간 포맷 불일치인 경우가 많다. [S1]

## 💻 코드 패턴 (Code patterns)
Exact date match, no time component (SQL):
```sql
SELECT * FROM Orders WHERE OrderDate='2025-11-11';
```

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual
- **출처 신뢰도:** B (W3Schools — widely used educational reference, not a primary standards body)
- **신뢰 점수:** 0.88
- **중복 검사 결과:** 신규 생성 (New discovery)

## 🔗 지식 그래프 (Knowledge Graph)
- **상위/루트:** [[SQL Tutorial]]
- **관련 개념:** [[SQL Between]], [[SQL Data Types]], [[SQL Where]]
- **참조 맥락:** 날짜/시간 컬럼을 다루는 모든 쿼리에서 포맷 불일치 버그를 예방하기 위해 참조.

## 📚 출처 (Sources)
- [S1] W3Schools — SQL Working With Dates — https://www.w3schools.com/sql/sql_dates.asp

## 📝 변경 이력 (Change history)
- 2026-07-04: Initial draft synthesized from the W3Schools "SQL Working With Dates" page (Astra wiki-curation, P-Reinforce v3.1 format).