이글 읽고, 심심해 못 견디시는 분은
자신이 사용하고 있는 DB와 버전과, 플랫폼을 함께 기제해서,
1000년 2월 28일 더하기 1일
결과를 리플로 달아주세요.
각 DB 들의 결과가 사뭇 궁금하네요. 제가 다양한 DB를 만질 수 없어서. ^^
저부터 시작하죠. ^^
$ uname -a Linux localhost 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005 i686 i686 i386 GNU/Linux [ioseph@memento ~]$ psql ioseph=> select version(); version --------------------------------------------------------------------------------------------------- PostgreSQL 8.1.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2) (1 row) ioseph=> select '1000-02-28'::date + '1 day'::interval; ?column? --------------------- 1000-03-01 00:00:00 (1 row)
sybase는 안됩니다~~~
datetime이 1753~ 시작이라서요~~
추가합니다~~~
12.5에서 새로운 type이 나왔네요~~~
date라고~~ㅋㅋㅋ...무식이 죕니다.
1> select dateadd(dd,1,convert(date,"10000228"))2> go
------------ Mar 1 1000
3월 1일이네요~~~
그리고 1973년의 기준이 뭔가 해서~~여러가지로 테스트 해봤는데요..모르겠네요..
저장은 이렇게 됩니다.(sybase에서는 datetime이 총 8byte로 되는데 앞의 4byte가..날자입니다)
19730101
...FFFF 2e46....
왜그런지는 못찾았습니다...찾으면 알려주세요~~
Altibase MMDBMS의 결과입니다.
% altibase -vversion 4.3.7.23 SPARC_SOLARIS_2.8-64bit-compat5-4.3.7.23-release-CC (sparc-sun-solaris2.8) Apr 3 2006 09:55:42, binary db version 4.9.2, meta version 4.7.1, cm protocol version 4.5.1, replication protocol version 4.6.1
% is------------------------------------------------------------- Altibase Client Query utility. Release Version 4.3.7.23 Copyright 2000, ALTIBASE Corporation or its subsidiaries. All Rights Reserved.--------------------------------------------------------------ISQL_CONNECTION = TCP, SERVER = 127.0.0.1, PORT_NO = 20599
iSQL> select dateadd('1000-02-28', 1, 'day') from dual;DATEADD('1000-02-28', 1, 'day')----------------------------------1000/03/01 00:00:001 row selected.
[minias@web minias]$ uname -a
Linux web 2.4.32 #1 Thu Dec 18 11:31:59 EST 2005 i686 unknown
mysql> SELECT VERSION();
+-------------+
| VERSION() |
| 3.23.58-log |
1 row in set (0.00 sec)
mysql> SELECT ADDDATE('1000-02-28', INTERVAL 1 DAY);
+---------------------------------------+
| ADDDATE('1000-02-28', INTERVAL 1 DAY) |
| 1000-03-01 |
windows2000 base MS-sql 2000
Microsoft® SQL Server™는 1753년에서 9999년 사이의 날짜로 인식할 수 없는 모든 값을 거부합니다.
1000년 2월 28일은 윤달인 듯한데요???
Oracle 경우
SQL> insert into Datesheet values('28-FEB-1000');
1 row created.
SQL> select * from datesheet;
TESTDATE---------11-JUL-0628-FEB-00
SQL> select TESTDATE+1 from datesheet;
TESTDATE+---------12-JUL-0629-FEB-00 => 1000년 2월 28일 + 1
SQL> select TESTDATE+2 from datesheet;
TESTDATE+---------13-JUL-0601-MAR-00
CUBRID의 경우
sqlx> insert into datesheet values('02/28/1000') sqlx> ;x
=== <Result of SELECT Command in Line 1> ===
testdate ============ 07/11/2006 02/28/1000
sqlx> select testdate+1 from datesheetsqlx> ;x
testdate+1============ 07/12/2006 02/29/1000
sqlx> select testdate+2 from datesheetsqlx> ;x
testdate+2============ 07/13/2006 03/01/1000
우찌 다른 DB에서 담달로 넘어갔는지..
흠...신묘막측하군요...^^;;
[root@linux ~]# sqlite3 /tmp/testSQLite version 3.3.5Enter ".help" for instructionssqlite> select date('1000-02-28', '+1 day');1000-03-01sqlite>
OS: WIN2K / FireBrid 1.5.3 / InterBase 6.5
create table test (f1 date);
insert into test (f1) values ('1000-02-28');
select f1, f1+1 from test;
-> '1000-02-28' , '1000-03-01'
지금까지의 결과를 정리해보면,
1000-03-01: PostgreSQL, Altibase, MySQL, SQLite, Firebird
1000-02-29: Oracle, CUBRID
Deny (?): Sybase, MS SQL
IBM DB2/Informix를 제외하고는 웬만한 DBMS 모두 테스트가 된 것 같습니다. 재미있네요... ^^
오라클이, 2월 29일로 처리하네요.
묘한 정책일쎄...
예상 했던 대로 각 DB 마다 다르게 처리하네요. ^^
재밌죠?
이 부분에 대한 더 재미난 것은 직접 인터넷을 뒤져보세요. 꽤나 재미난 날짜입니다.
새로 재미난 것이 생겼는데, 왜 몇몇 DB는 1753년부터 시작하는지가 궁굼해졌네요.
저희 직원이 말하길... 2000년에 2월 29일이 있었고, 4년 주기로 움직이니까 1000년이면 2월 29일이 맞다고 합니다... 이야기를 듣고 보니 그렇네요... ^^ CUBRID, Oracle win !!!
1000년 2월 28일...흠... 얄딱꾸리하네요..ㅡㅡ;;
IBM DB2의 경우
insert into datesheet values('1000-02-28')
select * from datesheet
1000-02-28
select testdate +1 days from datesheet
1000-03-01
흠... 희안하네요... 1006년 전으로 가서 달력을 봐야할 듯..ㅡㅡ;;
2000 년이 윤년이라 해서 1000년이 윤년이 되지는 않습니다.
아시다시피 윤년을 구하는 공식은 해당년이 400으로 나누어떨어지면 윤년 400으로 나눈 나머지값이 0이 아니고 100으로 나누어떨어지면 윤년이 아님. 400, 100으로 나눈 나머지가 0 이 아니지만 4로 나눈 나머지가 0 이면 윤년 인데...
위의 공식으로 한다면 1000 년이 윤년일까요? 아니죠...
리눅스의 cal 명령을 사용한 1000년의 2월 모습입니다.
그냥 참조만하세요;;
의도했던 결과였습니다.
얼마나 심심했으면.... 쯔쯔
윤년 계산 방식도 한가지가 아니네요;
옛날에는 나라마다 채택한 윤년 계산법도 달랐나봅니다.
가장 널리 쓰이는 그레고리력으로 계산하면 100으로 나누어 지는 해 중에서도 400으로 나누어지는 해가 아니면 윤년이 아닙니다. 4000으로 나누어지는 해도 윤년이 아니네요. 2만년에 하루 정도 오차가 생길 만큼 정확하다 합니다.
1600, 2000년은 그레고리력으로 윤년인데 1000년은 윤년이 아닙니다.
근데 문제는;; 그레고리력이 1582년에 되서야 이전의 달력체계가 가진 문제를 해결하기 위해 발표되었다는데 그 전에 흘러가 버린 날짜들 입니다 ㅋㅋ
새로운 달력을 기준으로 1582년 10월 4일을 기점으로 열흘씩 당겨졌다고 하는데 1000년 2월 당시의 윤년은 어떻게 계산되는지 모르겠습니다.
그레고리력적인 알고리즘(??)으로 따지면 1000년 2월 28일의 다음날은 3월 1일이 맞네요 ㅎㅎ
제가 알기로도 1000년은 윤년이 아닌걸로 압니다.
문제는 신기배님이 말씀하신거처럼,
윤년 계산 방식과 그것이 언제 적용되었느냐에 따라서 틀려지는듯 싶네요.
또한
MS SQL는 다른 DB의 엔진을 사다가 개선시킨것으로 아는데..
Sybase와 연관이 있는거 같네요 :()
이미 Ms-sql이 생길때 저러한 문제가 있었으므로
적정한 시점에서 책임논란이 있는 부분을 회피하고자
년도의 제한을 둔거 같습니다.
결국 오라클과 큐브리드가 바보가 된건가요? :D
그렇군요. 흠 그레고리력이 1582년 부터 썼으니깐 그 이전의 날짜는 그레고리력을 사용하면 안되겟군요.
율리우스력은 08년 부터 시작해서 100마다의 보정을 해주지 않고 그냥 4년마다 윤년으로 한다는군요.
세심한곳까지 신경을 썼군요...오라클과 큐브리드는...-0-
아 애매한것은요 ㅎㅎ;
1582년에 그레고리력이 발표되면서 열흘치 시간이 사라졌습니다. 그 이전까지의 달력과 실제 시간과의 차이를 되돌리기 위해서요. 1582년 10월 4일의 다음날은 10월 15일이 되었던 것인데요.
문제는 1000년 2월 29일이라는 윤달이 있었고 그걸 이 열흘로 모두 극복 했느냐 입니다.
1000년 2월 29일이라는 날짜도 그렇지만 1582년 10월 5~14일도 붕 뜬 셈입니다 ㅎㅎ;
가장 널리 쓰이는 그레고리력으로 계산한다면 1000년 2월 29일은 안나와야 맞습니다. 율리우스력으로 시간이 흘러간 DBMS라면 다른 시간차원에 있을듯 ㅎ;
만일 오라클과 큐브리드의 경우
1000-2-29 의 날짜가 세심한 처리에 의한 결과라고 가정한다면..
신기배님이 말씀하신 1582-10-5~14 일의 데이터가
표시 되야 할까요? 되지 않아야 될까요?
현재 사용하는 계산법에 의해서 보정된 만큼..
기존의 사용했던 계산법은 사용하지 않아야 됩니다.
team_b님의 말씀처럼 율리우스력을 사용했다고 가정한다면..
위의 10일치는 반드시 오류가 나야 할듯 싶은데..
아마도..
세심한 처리보다는 다른 이유가 있지 않을까 생각해봅니다. :D
흠...그레고리력의 원년 즉 1582년 이전의 날짜는 율리우스력으로 계산해야 하는데, 율리우스력이 바로 그레고리력으로 매칭이 안되죠...10일이 비죠...그 사라진 10일을 채우기 위해 보정일수가 존재 합니다. (사라진 10일을 그대로 내비뒀겟습니까? -0-)
제가 '세심한 처리' 라고 했던 이유는 1582년 이전의 윤년을 찾기위해서 그레고리력에서 사용하는 윤년공식을 사용하지 않고 율리우스력에서 사용하는 윤년공식을 사용했다는 이유때문이였습니다.
