Có một hằng số cho thời gian cuối của thời gian không?

Đối với một số hệ thống, giá trị thời gian 9999-12-31 được sử dụng làm "thời gian kết thúc" là thời gian kết thúc mà máy tính có thể tính toán. Nhưng nếu nó thay đổi thì sao? Sẽ không tốt hơn nếu định nghĩa lần này là biến dựng sẵn?

Trong C và các ngôn ngữ lập trình khác thường có một biến như MAX_INThoặc tương tự để lấy giá trị lớn nhất mà một số nguyên có thể có. Tại sao không có chức năng tương tự, MAX_TIMEtức là đặt biến thành "thời gian kết thúc" mà đối với nhiều hệ thống thường là 9999-12-31. Để tránh vấn đề mã hóa cứng thành một năm sai (9999), các hệ thống này có thể đưa ra một biến cho "thời gian kết thúc" không?

** Ví dụ thực tế **

End of validity date: 31/12/9999.(tài liệu chính thức được liệt kê như thế này) Các blogger muốn viết một trang luôn luôn ở trên đầu, trang chào mừng. Vì vậy, nó được đưa ra một ngày càng xa trong tương lai càng tốt:

3000? Có, trang chào mừng mà bạn phải đối mặt được đăng vào ngày 1 tháng 1 năm 3000. Vì vậy, trang này sẽ được giữ trên đầu blog mãi mãi =) Nó thực sự được đăng vào ngày 31 tháng 8 năm 2007.

Hãy tự hỏi tại sao bạn cần một biến như vậy ở nơi đầu tiên.

Rất có thể, bạn đang nói dối về dữ liệu của mình: bất cứ khi nào bạn cần một biến "kết thúc thời gian", bạn không đề cập đến thời gian kết thúc thực tế; thay vào đó, bạn đang bày tỏ những điều như "không có giới hạn trên cho ngày này", "sự kiện này tiếp diễn vô thời hạn" hoặc tương tự.

Sau đó, giải pháp chính xác là thể hiện trực tiếp các ý định này thay vì dựa vào giá trị ma thuật: sử dụng các loại ngày không thể (trong đó nullbiểu thị "không có ngày kết thúc"), thêm trường boolean "không xác định", sử dụng trình bao bọc đa hình (có thể có thể là một ngày thực sự hoặc một giá trị "không xác định" đặc biệt) hoặc bất cứ điều gì ngôn ngữ lập trình của bạn cung cấp.

Tất nhiên, giải pháp chính xác không phải lúc nào cũng khả thi, vì vậy cuối cùng bạn có thể sử dụng một giá trị ma thuật, nhưng khi bạn làm, bạn phải quyết định một giá trị phù hợp trên cơ sở từng trường hợp, bởi vì ngày nào có và không có ý nghĩa tùy thuộc vào miền bạn đang lập mô hình - nếu bạn đang lưu trữ dấu thời gian nhật ký, 01/01/2999 là "thời gian kết thúc" hợp lý; cơ hội ứng dụng của bạn vẫn đang được sử dụng gần 1000 năm kể từ bây giờ, tôi sẽ nghĩ rằng, thực tế là bằng không. Cân nhắc tương tự đi cho các ứng dụng lịch. Nhưng điều gì sẽ xảy ra nếu phần mềm của bạn xử lý dữ liệu khoa học, giả sử, dự đoán dài hạn về khí hậu Trái đất? Những người thực sự có thể muốn nhìn một ngàn năm tới tương lai. Hoặc tiến thêm một bước; thiên văn học, một lĩnh vực mà nó hoàn toàn bình thường để suy luận trong những khoảng thời gian rất lớn theo thứ tự hàng tỷ năm, cả vào con đường và tương lai. Đối với những người đó, 01/01/2999 là một mức tối đa tùy ý hoàn toàn vô lý. OTOH, một hệ thống lịch có khả năng xử lý thời gian mười nghìn tỷ năm trong tương lai hầu như không thực tế đối với hệ thống theo dõi cuộc hẹn nha sĩ, nếu chỉ vì khả năng lưu trữ.

Nói cách khác, không có sự lựa chọn tốt nhất cho một giá trị sai và tùy ý theo định nghĩa để bắt đầu. Đây là lý do tại sao thật sự không phổ biến khi thấy một định nghĩa trong bất kỳ ngôn ngữ lập trình nào; những cái thường không đặt tên nó là "kết thúc thời gian", mà là một cái gì đó như DATE_MAX(hoặc Date.MAX), và lấy nó để có nghĩa là "giá trị lớn nhất có thể được lưu trữ trong kiểu dữ liệu ngày", không phải là "kết thúc thời gian" hoặc "vô thời hạn".

Là một ngành công nghiệp, chúng tôi đã nổi tiếng thiển cận và độc đoán trong việc theo đuổi việc tiết kiệm một vài byte, ví dụ

• Ngày 31 tháng 12 năm 99
• Ngày 19 tháng 1 năm 2038
• T + 50 năm, khi hy vọng tất cả các hệ thống mà tôi tham gia đã không còn tồn tại hoặc bị thay thế (hoặc tôi đã chết, tùy theo điều kiện nào đến trước).

IMHO đặt cược tốt nhất là ở lại với mức độ trừu tượng chính thống, phù hợp vào 'ngày tối đa', và hy vọng rằng một giải pháp chung đã giải quyết vấn đề trước khi thời gian đến.

ví dụ: trong .NET, DateTime.MaxValue là tùy ý 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000. Vì vậy, nếu các giả định của tôi về tuổi thọ của tôi là sai và năm 10000 đến, tôi hy vọng rằng việc biên dịch lại ứng dụng của tôi với phiên bản sau của khung sẽ mở rộng DateTime.MaxValue(ví dụ: bằng cách thay đổi loại cơ bản của nó) thành giá trị tùy ý mới và đưa vấn đề đi xa hơn trong vài thiên niên kỷ.

Biên tập

.

Thay thế cho việc sử dụng null, có hậu quả tiêu cực là loại tương thích với bất kỳ loại tham chiếu nào (bao gồm .Net Nullable`), có thể sẽ gây ra sự cố NRE ở người tiêu dùng quên kiểm tra, trong ngôn ngữ FP, thông thường sử dụng một Tùy chọn hoặc Có thể Loại trình bao bọc xung quanh một giá trị có thể hoặc không thể được trả về.

Mã giả:

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

Lợi ích của việc này là buộc người tiêu dùng phải suy luận về cả hai trường hợp. Khớp mẫu cũng phổ biến ở đây:

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

Bạn có thể muốn một algebraic data typebiến thể cho vô hạn lớn date. Sau đó xác định so sánh, trong đó infinitebiến thể sẽ luôn lớn hơn bất kỳ biến thể nào khác date.

Ví dụ trong Scala:

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

Lưu trữ thời gian của bạn dưới dạng số dấu phẩy động chính xác kép 64 bit IEE754 và bạn có thể sử dụng +INF. Không sử dụng độ chính xác đơn, chỉ chính xác đến 7 chữ số, hơi thấp cho một ngày.

Ca cao / Objective-C có các phương thức xuất xưởng [NSDate distantPast] và [NSDate distantFuture] đại diện chính xác cho loại điều bạn đang đề cập đến.

Các giá trị được trả về bởi việc triển khai hiện tại là các hằng số đại diện cho khoảng 0 AD và 4000 AD, mặc dù các giá trị này không được bảo đảm hoặc ghi lại.

Nhìn chung không có giá trị như vậy, vì nó sẽ không hữu ích khi xây dựng ngôn ngữ.

MAX_INTvà đó là tất cả phục vụ một mục đích. Chúng có thể được sử dụng trong mã của bạn để kiểm tra chống tràn. Điều này rất hữu ích nếu bạn sẽ tạo và quản lý các đối tượng dữ liệu lớn trong mảng, vectơ, bất cứ điều gì. Đó cũng là một giá trị khá cụ thể nền tảng.

Trường hợp sử dụng cho một MAX_DATEgiá trị là khó khăn hơn để xem. Thông thường, đây chỉ là các giá trị, chúng không được sử dụng như một phần trong cấu trúc của chương trình và do đó, giá trị xoay quanh sẽ không gây ra hậu quả thảm khốc cho chương trình (mặc dù có thể là dữ liệu). Ngoài ra, các loại ngày và giờ trong C, C ++, vv thường được xác định chặt chẽ hơn; và vì vậy những người viết chương trình không phải lo lắng rằng nó có thể thay đổi giữa các nền tảng.

Trong một dự án mà chúng tôi đã thực hiện, chúng tôi đã có một tình huống trong đó việc định cỡ một số cơ sở dữ liệu được thực hiện theo cách không bền vững sau 30 năm sử dụng phần mềm. Khi khách hàng hỏi kỹ sư trưởng của chúng tôi vào thời điểm đó: "Chà, chúng ta sẽ làm gì sau 30 năm sử dụng phần mềm của bạn?" Kỹ sư trưởng của chúng tôi, lạnh lùng như một quả dưa chuột, trả lời với một cái nhún vai: "Chúng tôi sẽ đi uống bia!"

Vấn đề là, chỉ cần sử dụng ngày là đủ xa trong tương lai. Rất có thể phần mềm của bạn sẽ được nâng cấp hoặc thay thế sau đó. :)