데이터베이스 엔진이 쿼리를 최적화 할 수있는 인덱스 또는 기본 기능을 사용할 수 있기 때문이다. 대형 데이터 세트에서 하나의 데이터베이스 쿼리 (초)의 성능에 미치는 영향 (안 밀리 초)을 의미.

표준 SQL 거의 동일한 기본 형식, 같은 ISO 8601을 정의합니다.

(예, SQLite는 단지 텍스트 문자열을 지원하지만 가능성이 매우 어쨌든 엔진에 제한되도록 SQLite는은, 어느 쪽이든 많은 데이터 유형을 지원하지 않습니다.)

적절한 데이터 형식을 인덱싱 할 수있는 값의 고유 필터링 및 정렬을 허용한다. SQL 쿼리에서 취급 UNIX 타임 스탬프를 다루는만큼 간단합니다.

개인 (세분화 된) 날짜 구성 요소는 생략 할 수 없지만, 간결하고 정확한 데이터 저장을 위해, "올 데이 '와 유사한 같은 속성은 별도로 날짜 어느 쪽이든 당 깃발을 보관해야한다 (그들이하지 않는 한 특정 추가 사용 사례입니다 처음부터 모든 날짜에 적용, 예를 들면되지 컨텐츠 생성 날짜를 수정)합니다.

우리가 핵심으로 그것을 얻을 수 있다면 기본 날짜 필드를 사용하여 상관 없어. 그러나 나는 이미 그 싸움을 싸우고 시도 잃었다. 그리고 나는 핵심 커미터 핵심에있는 날짜 필드를 허용하지 않습니다 풍부하게 명확하게 된 때 기본 날짜 필드를 사용하는 솔루션을 만들 않을거야.

오후 4시 41분 4 월 10 일 2012 arlinsandbulte에 의해 게시 됨

MM : SS 형식 일관성을 쉽게 검색 및 정렬을 유지하기 위해 나는 우리가 YYYY-MM ISO 형식으로 저장된 ISO 형식을 제한해야합니다 생각한다.
과거의 넓은 범위를 허용하도록 SS 포맷 : MM : 어쩌면 ± Y YYYY-MM-ISO 형식을 사용 date.module의 일반적인 요구하고있다 미래의 날짜,. 그러나, PHP의 날짜 처리는 제한 어쨌든있을 수 있습니다.

또한,이 ISO 표준은 정렬 및 검색을 더 어렵게 만들 수도 있습니다 그렇게 정확도를 줄이기 위해 덜 중요한 부분을 삭제 할 수 있습니다에도 불구하고. 이러한 이유로, 우리는 여전히 각 파트에 대한 '뭔가'를 저장해야 할 수도 있습니다. (만약 내가 잘못 제발 올바른. 나는 데이터베이스 전문가가 아니다).
-와일드 생각 : 우리는 어떤 취소 필요한 날짜 부분에 '99'을 저장할 수 있습니다. 그 년을 제외한 모든 부품의 작동뿐만 아니라 저장된 날짜 문자열이 아닌 ISO 준수합니다.

7:57 pm에 2012 년 4 월 9 데이비드 스트라우스에 의해 게시 됨

ISO 8601은 시간대를 처리하는 방법은 꽤 뇌사이다. 시간대는 사용자 / 콘텐츠 항목 현지화 우려 날짜는 UTC 어떻게 다른지에 대한 주석에 저장된 날짜에 미리 조정해야하지 뭔가. 그것은 읽을 데이터가 하드하게하고 (ISO 날짜와 달리 고체) 문자열 정렬을 나누기.

우리가 데이터베이스에 UTC / 줄루 시간을 사용하여 붙은 경우, I는이 제안을 지원할 수 있습니다. 내가 유닉스 시대의 타임 스탬프를 사용하여 우리의 역사를 사랑했던 주요 것은 그들이 UTC 항상있어 알고있다.

오전 11시 19분 4 월 (11) 2012 카렌족에 의해 게시 됨

예, 여부 /하는 저장 UTC로 시간을 변환하는 경우에 대한 문제는 별개의 문제이며, 우리는 그것에 대해 별도의 논의가 필요합니다. ISO 문자열에 시간대 정보를 추가 할 수있는 옵션을 가지고 있지만, 사실은 우리가, 난 그냥 가능하다는 것을 지적 것을 할 것을 제안하고 있지 않다. 나는 그 주제 (또는 다른 수있는 사람)에 대한 별도의 문제를 열 ​​계획입니다.

ISO 표준이가는 많은 계획을 가지고, 많은 사람들이 이미 날짜로 표시해야하고 그것을 위해 보편적으로 이해되는 형식을 만든 일을 생각했다. 네이티브 데이터베이스 날짜 필드는 실제로 너무 그것을 사용할 수 있습니다.

그렇게 우리는 BC 날짜를 지원할 수에 접두사, 그것은 우리에게 수년에 걸쳐 요청 된 거의 모든 것을 줄 것이다 - 나는 +를 추가 할 않습니다. 다른 형식에서이 형식으로 /에서 변환은 PHP로 처리 할 수 ​​있습니다. 그리고 시간대 변환은 PHP로 처리 할 수 ​​있습니다.

문제가 될 수 있습니다 나머지 문제는 INT (타임 스탬프) 및 기본 날짜 필드 대 문자열의 성능, 그래서 실제 비용이 무엇인지 알아 내기 위해 그것에 대해 별도의 논의를 시작하고 우리는 성능이 좋은 만들기 위해 무엇을 할 수 있는지 가능한 한. 데이터베이스 이식성을 고려할 때,이 포함 된 VARCHAR 필드에 ISO는 큰 우승자이다.

오후 1시 52분 4 월 (11) 2012 arlinsandbulte에 의해 게시 됨

정렬에 문제를 제기 - (가) + 추가 것인가?
하는 YYYY-MM-DD 문자열 오름차순으로 정렬 자연스럽게 첫 번째 (올바른 순서로 가장 빠른 날짜 결과 - +가없이 최신 날짜 마지막).
단, +를 추가하면 - 그 변경됩니다. 가장 이른 날짜에 최신 날짜로 정렬 날짜 - 모든 + 날짜에 간단한 오름차순 문자열 정렬 결과는 첫째, 모든 다음 최신 날짜에 이른 날짜로 분류.

예를 들어, 다음 해 전용 문자열의 정렬 된 목록입니다 :
"0000"
"1800"
"1900"
"1977"
"2000"
"2012"
"-0100"
"-0500"
"-1000"
"-5000"

오전 1시 50분 9 월 (27) 2012 년 앨런 D.에 의해 게시 됨

퇴보 이러한 DB 필드를 지원하지 않는 미친 것으로 보인다. 날짜 부가 물건을 모두 제외하고, 그것은 대규모 모듈 및 모든 다른 시스템에 I가 일을 한 날짜 지원 클래스 코드 1000 개 정도 라인의 사소한 클래스입니다.

그래서이 DB 드라이버 코더로 이동 뾰족한 질문은 정말, 날짜 시간 필드는 의사 날짜 시간 필드를 지원하기 위해 내부적으로 변환 할 수 있을까?

개별 구성 요소로 분할 밖으로 열이 길을 가고 권하고 싶지 않다 정말 작동하지만 (나는 부분 날짜에했던 것처럼) 아주 지저분합니다. 나는이 일을 발에서 자신을 촬영 이후 릴리스에서이 되 돌리는 보는 것 같은 느낌.

만약 내가 기억 빼기 기호 내가 올바르게 ASCII 테이블을 읽고 있어요 경우 정렬 문제를 부정하는 필요하므로 다시 이소 사양을 다시 읽기 (또는 테스트를 실행)없이, 긍정적 인 신호는 선택 사항입니다. (- 45, 48 및 0에서 57까지의 범위 9). 의 + (ASCII 43)를 사용하여 여기에 종류를 나누기.

시간대 지원 (또는 부족)

난 단지 데이터베이스에 하나의 시간대를 사용하여 그것을 주문 및 기본 날짜 DB 필드를 지원하지 않을 경우 데이터를 검색에서 제외의 일부를 부정으로 (UTC) 최고라고 동의합니다.

한 두 개의 링은 그들 모두를 지배 하는가?

나는이 일에 동의, 우리는 지원하는 확장 된 형식의 매우 간단한 서브 세트에이를 제한해야합니다. 어쩌면 단지

날짜 모듈과 현재 지원하지 않으나, 타임 존 정보는 날짜에 의미가 있습니까, 미국에서 2012-01-01 호주에서 2012-01-01 뒤에 거의 하루 종일입니다. 그래서 어쩌면 현장 지원은 ISO와 같은 필드와 시간대를 지원하는 ISO와 같은 필드까지 줄일 수있다? 이 시간 지원을 삭제,하지만 핵심은 시간 필드를 지원해야한다고 생각하지 않습니다.

마지막으로, 드루팔 8 기능 동결 : 12 월 1 일, 2012