"종료"에 대한 상수가 있습니까?

일부 시스템의 경우 시간 값 9999-12-31은 컴퓨터가 계산할 수있는 시간의 끝으로 "시간 끝"으로 사용됩니다. 그러나 그것이 바뀌면 어떻게 될까요? 이번에는 내장 변수로 정의하는 것이 낫지 않습니까?

C 및 기타 프로그래밍 언어에는 일반적으로 MAX_INT정수가 가질 수있는 가장 큰 값을 얻는 것과 같은 변수 가 있습니다. 비슷한 기능이없는 이유는 무엇입니까? MAX_TIME즉, 많은 시스템에서 일반적으로 9999-12-31 인 "종료 시간"으로 변수를 설정하십시오. 잘못된 연도 (9999) 로의 하드 코딩 문제를 피하기 위해이 시스템은 "종료 시간"에 변수를 도입 할 수 있습니까?

** 실제 예 **

End of validity date: 31/12/9999.(공식 문서는 다음과 같습니다.) 블로거는 항상 맨 위에있는 페이지 (환영 페이지)를 작성하려고합니다. 따라서 가능한 한 미래에 날짜가 주어집니다.

3000? 예, 직면하고있는 시작 페이지는 3000 년 1 월 1 일에 게시됩니다. 따라서이 페이지는 블로그 맨 위에 계속 유지됩니다 =) 실제로 2007 년 8 월 31 일에 게시됩니다.

왜 그런 변수가 필요한지 스스로에게 물어보십시오.

아마도 당신은 당신의 데이터에 대해 거짓말을하고있을 것입니다. "종료 시간"변수가 ​​필요할 때마다, 당신은 실제 시간의 끝을 언급하지 않습니다; 오히려 "이 날짜에는 상한선이 없습니다", "이 사건은 무기한 계속됩니다"또는 이와 유사한 내용을 표현하고 있습니다.

올바른 해결책은 마법 값에 의존하지 않고 이러한 의도를 직접 표현하는 것입니다. nullable 날짜 유형 ( null"끝 날짜 집합 없음"을 나타냄)을 사용하고 "무한"부울 필드를 추가하고 다형성 래퍼를 사용합니다 ( 실제 날짜 또는 특수한 "무한"값이거나 프로그래밍 언어가 제공하는 모든 것이 될 수 있습니다.

물론 올바른 솔루션이 항상 실현 가능한 것은 아니므로 결국 마법의 가치를 사용하게 될 수도 있지만, 그렇게 할 때는 날짜별로 적절한 가치를 결정해야합니다. 로그 타임 스탬프를 저장하는 경우 01/01/2999는 합리적인 "종료 시간"입니다. 지금까지 거의 1000 년 동안 응용 프로그램을 계속 사용할 가능성은 거의 제로입니다. 캘린더 응용 프로그램에 대해서도 비슷한 고려 사항이 적용됩니다. 그러나 소프트웨어가 지구 기후에 대한 장기 예측과 같은 과학적 데이터를 처리하려면 어떻게해야합니까? 그들은 실제로 천 년을 미래로 바라 볼 수 있습니다. 또는 한 걸음 더 나아가십시오. 천문학, 수십억 년에 이르는 매우 큰 시간 간격으로 추론하기에 완전히 정상적인 분야, 길과 미래로. 이를 위해 01/01/2999는 완벽하게 어리석은 임의의 최대 값입니다. 10 조 년의 시간을 미래에 처리 할 수있는 캘린더 시스템 인 OTOH는 스토리지 용량만으로도 치과 예약 추적 시스템에는 거의 실용적이지 않습니다.

다시 말해, 정의에 따라 잘못되고 임의적 인 값으로 시작하는 최선의 선택은 없습니다. 그렇기 때문에 프로그래밍 언어로 정의 된 언어를 보는 것이 일반적이지 않습니다. 일반적으로 이름을 "시간 끝"으로 지정하지 않고 DATE_MAX(또는 Date.MAX) 와 같은 것으로 "시간 끝"이 아니라 "날짜 데이터 유형에 저장할 수있는 가장 큰 값"또는 "무한대로".

산업으로서 우리는 몇 바이트를 절약하려는 노력에있어 근시안적이고 임의적이었다.

• 12 월 31 일 99
• 2038 년 1 월 19 일
• T + 50 년, 내가 참여했던 모든 시스템이 소진되었거나 교체되었을 때 (또는 내가 죽었을 때 중 더 빠른 날)

IMHO의 최선의 방법은 '최대 날짜'에 대한 적절한 주류 수준의 추상화를 유지하고 시간이 오기 전에 일반적인 해결책이 문제를 해결하기를 희망하는 것입니다.

예를 들어 .NET에서 DateTime.MaxValue 는 임의로 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000있습니다. 따라서 내 장수에 대한 내 가정이 거짓이고 10000 년이되면, 차기 버전의 프레임 워크로 내 앱을 다시 컴파일하면 DateTime.MaxValue(예 : 기본 유형을 변경하여) 새로운 임의의 값으로 확장되기를 바라고 있습니다 몇 천년 동안 문제를 더 쫓아냅니다.

편집하다

(tdammers의 주장에 따르면 인공적인 날짜를 밝히지 않고 종료 날짜가 없다는 사실을 소비자에게 분명히 강조하는 것이 더 정확합니다.)

을 사용하는 대안으로 null.Net Nullable을 포함한 모든 참조 유형과 호환되는 유형의 부정적인 결과가 발생하여 FP 언어에서 확인을 잊어 버린 소비자의 NRE 문제가 발생할 수 있습니다. Option 또는 Maybe Type 래퍼는 반환되거나 반환되지 않을 수있는 값을 둘러싸고 있습니다.

의사 코드 :

Option<DateTime> LeaseExpiryDate(Home rental) 
{
    if (... expiry date can be determined ...)
       return Some(rental.ExpiryDate);
    else
       return None;
}

이렇게하면 소비자가 두 경우 모두에 대해 추론해야한다는 이점이 있습니다. 패턴 일치도 여기에서 일반적입니다.

LeaseExpiryDate(myHome) match {
     case Some(expiryDate) => "Expired"
     case None => "No Expiry"
}

당신은 아마 algebraic data type무한의 큰 변형을 원할 것입니다 date. 그런 다음 infinite변형이 항상 다른 것보다 큰 비교를 정의 하십시오 date.

스칼라의 예 :

sealed abstract class SmartTime extends Ordered[SmartTime] { x =>
        def compare(y: SmartTime) = {
                x match {
                        case InfiniteFuture => 1
                        case InfinitePast => -1
                        case ConcreteTime(x) =>
                                y match {
                                        case InfiniteFuture => -1
                                        case InfinitePast => 1
                                        case ConcreteTime(y) => x compare y
                                }
                }
        }
}
case class ConcreteTime(t: Long) extends SmartTime
case object InfiniteFuture extends SmartTime
case object InfinitePast extends SmartTime

http://ideone.com/K5Kuk

64 비트 IEE754 배정 밀도 부동 소수점 숫자로 시간을 저장하면 사용할 수 있습니다 +INF. 단 정밀도를 사용하지 마십시오. 날짜에 비해 조금 낮은 7 자리까지만 정확합니다.

Cocoa / Objective-C에는 여러분이 말하는 종류를 정확하게 나타내는 팩토리 메소드 [NSDate distantPast] 및 [NSDate distantFuture]가 있습니다.

현재 구현에 의해 반환되는 값은 0 AD 및 4000 AD를 나타내는 상수이지만 보증되거나 문서화되어 있지는 않습니다.

언어 구성으로 유용하지 않기 때문에 일반적으로 그러한 가치는 없습니다.

MAX_INT그리고 그것은 모두 목적을 제공합니다. 오버플로를 확인하기 위해 코드에서 사용할 수 있습니다. 이것은 배열, 벡터 등으로 큰 데이터 객체를 생성하고 관리하려는 경우에 유용합니다. 또한 플랫폼 고유의 가치이기도합니다.

MAX_DATE값 의 유스 케이스 는보기가 더 어렵습니다. 일반적으로 이들은 단지 값일 뿐이며 프로그램 구조의 일부로 사용되지 않으므로 주변을 돌고있는 값은 프로그램에 치명적인 결과를 초래하지 않습니다 (데이터에 영향을 줄 수 있음). 또한 C, C ++ 등의 날짜 및 시간 유형은 일반적으로보다 엄격하게 정의됩니다. 따라서 프로그램을 작성하는 사람들은 플랫폼간에 변경 될 수 있다고 걱정할 필요가 없습니다.

우리가 수행 한 한 프로젝트에서 소프트웨어 사용 후 30 년이 지나도 지속될 수없는 방식으로 일부 데이터베이스 크기 조정이 수행되는 상황이있었습니다. 고객이 당시 수석 엔지니어에게 다음과 같이 물었을 때 "음, 30 년 동안 소프트웨어를 사용한 후에 우리는 무엇을 할 것입니까?" 오이처럼 시원한 우리의 수석 엔지니어는 어깨를 으 with하며 대답했습니다. "우리는 맥주를 마실 것입니다!"

요점은 미래에 충분한 날짜를 사용하는 것입니다. 소프트웨어가 업그레이드되거나 교체 될 가능성이 있습니다. :)