2nd/10_Wiki/Dev/Topic_SQL/SQL_Dates.md

id, title, category, status, verification_status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, created_at, updated_at, review_reason, merge_history, tags, raw_sources, applied_in, github_commit

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

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):

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).