“Zamanın sonu” için bir sabit var mı?

Bazı sistemlerde, 9999-12-31 zaman değeri, bilgisayarın hesaplayabileceği zamanın sonu olarak "zaman sonu" olarak kullanılır. Peki ya değişirse? Bu zamanı yerleşik bir değişken olarak tanımlamak daha iyi olmaz mıydı?

C ve diğer programlama dillerinde genellikle MAX_INTbir tamsayının sahip olabileceği en büyük değeri elde etmek için benzer veya benzer bir değişken vardır. Diğer bir MAX_TIMEdeyişle, değişkeni birçok sistem için genellikle 9999-12-31 olan "zaman sonu" olarak ayarlamak için benzer bir işlev yoktur. Hatalı bir yıla (9999) kodlama sorununu önlemek için bu sistemler "zaman sonu" için bir değişken getirebilir mi?

** Gerçek örnek **

End of validity date: 31/12/9999.(resmi belgeler şu şekilde listelenir) Blogger, her zaman en üstte olan bir sayfayı, hoş geldiniz sayfasını yazmak istiyor. Bu nedenle, gelecekte mümkün olduğunca uzun bir tarih verilir:

3000? Evet, karşı karşıya olduğunuz karşılama sayfası 1 Ocak 3000'de yayınlandı. Bu nedenle bu sayfa blogun üstünde sonsuza kadar saklanacak =) Aslında 31 Ağustos 2007'de yayınlandı.

İlk başta neden böyle bir değişkene ihtiyacınız olduğunu kendinize sorun.

Büyük olasılıkla, verileriniz hakkında yalan söylüyorsunuz: "zaman sonu" değişkenine ihtiyacınız olduğunda, gerçek zaman sonundan bahsetmiyorsunuz; bunun yerine "bu tarih için bir üst sınır yoktur", "bu olay süresiz olarak devam eder" veya benzeri şeyleri ifade ediyorsunuz.

Doğru çözüm, bu durumda, sihirli bir değere güvenmek yerine bu niyetleri doğrudan ifade etmektir: boş değerli tarih türleri kullanın (burada null"bitiş tarihi ayarlanmadı" anlamına gelir), "belirsiz" bir boole alanı ekleyin, bir polimorfik sarmalayıcı ( gerçek bir tarih veya özel bir "belirsiz" değer) veya programlama dilinizin sunduğu her şey olabilir.

Tabii ki, doğru çözüm her zaman mümkün değildir, bu nedenle sonuçta sihirli bir değer kullanabilirsiniz, ancak bunu yaptığınızda, her bir vaka için uygun bir değere karar vermeniz gerekir, çünkü hangi tarihler geçerlidir ve yoktur mantıklı modelleme yaptığınız alana bağlıdır - günlük zaman damgalarını saklıyorsanız 01/01/2999 makul bir "zaman sonu" dur; Başvurunuzun neredeyse 1000 yıl boyunca kullanılma şansı, tahmin ederim, pratikte sıfır. Benzer uygulamalar takvim uygulamaları için de geçerlidir. Peki ya yazılımınız dünya iklimiyle ilgili uzun vadeli tahminler gibi bilimsel verileri ele alacaksa? Bunlar aslında geleceğe bin yıl bakmak isteyebilirler. Veya bir adım daha ileri götürün; milyarlarca yıl boyunca çok büyük zaman aralıklarında mantık yürütmenin tamamen normal olduğu bir alan olan astronomi, hem yola hem de geleceğe. Bunlar için 01/01/2999 mükemmel bir saçma keyfi maksimum. Gelecekte on trilyon yıllık zaman aralıklarını idare edebilen bir takvim sistemi olan OTOH, sadece depolama kapasitesi nedeniyle bir diş hekimi randevu izleme sistemi için pek pratik değildir.

Başka bir deyişle, tanımı gereği yanlış ve keyfi olan bir değer için en iyi tek seçenek yoktur. Bu nedenle herhangi bir programlama dilinde tanımlanmış bir tanesini görmek gerçekten nadirdir; bunu genellikle "zaman sonu" olarak adlandırmaz, aksine DATE_MAX(veya Date.MAX) gibi bir şey söyler ve "tarih veri türünde depolanabilecek en büyük değer" anlamına gelir, "zaman sonu" veya "süresiz".

Bir endüstri olarak, birkaç bayt tasarruf etme arayışında kötü bir şekilde kısa görüşlü ve keyfi olduk.

• 31 Aralık 99
• 19 Ocak 2038
• T + 50 yıl, umarım dahil olduğum tüm sistemler geçersiz hale gelir veya değiştirilirse (veya hangisi önce gelirse).

IMHO en iyi seçenek, 'maksimum tarihte' uygun, ana akım bir soyutlama düzeyiyle kalmak ve ortak bir çözümün, zaman gelmeden sorunu ele almasını ummaktır.

örneğin .NET'te, DateTime.MaxValue isteğe bağlıdır 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000. Dolayısıyla, kendi ömrüm hakkındaki varsayımlarım yanlışsa ve 10000 yılı geldiğinde, uygulamamın çerçevenin daha sonraki bir sürümüyle yeniden derlenmesinin DateTime.MaxValue(örneğin, altta yatan türünü değiştirerek) yeni bir keyfi değere uzanacağını umuyorum. ve birkaç bin yıl boyunca sorunu daha da aşağıya taşıyın.

Düzenle

(Tdammers'ın güçlendirilmesi, yapay bir tarihi yumuşatmak yerine, tüketiciye bir bitiş tarihimiz olmadığı gerçeğini açıkça vurgulamanın daha doğru olduğuna işaret ediyor.)

nullHerhangi bir referans türüyle (.Net Nullable` dahil) uyumlu olmanın olumsuz bir sonucuna sahip olan ve alternatif olarak FP dillerinde kontrol etmeyi unutan tüketicilerde NRE sorunlarına neden olacak olan kullanımına alternatif olarak , Seçenek veya Belki Geri döndürülebilen veya döndürülemeyen bir değerin etrafına sarıcı yazın.

Sahte kod:

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

Bunu yapmanın yararı, tüketiciyi her iki durumda da akıl yürütmeye zorlamasıdır. Örüntü eşleştirme burada da yaygındır:

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

Muhtemelen algebraic data typesonsuz büyük için bir varyant istersiniz date. Ardından, infinitevaryantın her zaman diğerlerinden daha büyük olacağı karşılaştırmayı tanımlayın date.

Scala'da örnek:

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

Sürelerinizi 64 bitlik IEE754 çift kesinlikli kayar nokta sayısı olarak saklayın ve kullanabilirsiniz +INF. Tek kesinlik kullanmayın, bu sadece bir tarih için biraz düşük olan 7 basamak için doğrudur.

Kakao / Objective-C, tam olarak bahsettiğiniz şeyleri temsil eden fabrika yöntemleri [NSDate distantPast] ve [NSDate distantFuture] 'e sahiptir.

Mevcut uygulama tarafından döndürülen değerler, yaklaşık 0 AD ve 4000 AD'yi temsil eden sabitlerdir, ancak bunlar garanti edilmemekte veya belgelenmemektedir.

Genellikle böyle bir değer yoktur, çünkü bir dil kurgusu olarak yararlı olmaz.

MAX_INTve akraba hepsi bir amaca hizmet eder. Taşmalara karşı kontrol etmek için kodunuzda kullanılabilirler. Eğer dizilerde, vektörlerde, her neyse büyük veri nesneleri oluşturacak ve yönetecekseniz bu yararlı olur. Aynı zamanda oldukça platforma özgü bir değerdir.

Bir MAX_DATEdeğerin kullanım durumunu görmek daha zordur. Tipik olarak bunlar sadece değerlerdir, programın yapısının bir parçası olarak kullanılmazlar ve bu nedenle etrafında dönen değerin program için dezavantajlı sonuçları olmaz (veriler için olabilir). Ayrıca, C, C ++ vs.'deki tarih ve saat türleri genellikle daha kesin olarak tanımlanır; ve böylece programı yazan kişilerin platformlar arasında değişebileceğinden endişe etmeleri gerekmez.

Yaptığımız bir projede, yazılımın 30 yıllık kullanımından sonra sürdürülebilir olmayacak şekilde bazı veritabanlarının boyutlandırılmasının yapıldığı bir durum vardı. Müşteri o zaman baş mühendisimize sorduğunda: "Peki, yazılımınızı kullandıktan 30 yıl sonra ne yapacağız?" Salatalık gibi havalı baş mühendisimiz bir omuz silkerek cevap verdi: "Gidip bir bira içelim!"

Mesele şu ki, gelecekte yeterince uzun olan tarihi kullanın. Muhtemelen yazılımınız yükseltilecek veya değiştirilecektir. :)