Önerilen Tek Tip Gün ve Saat Belirtimi

Genel Bakış

Konu: ARPANET host'ları arasında tarih ve saat temsilinin standardizasyonu.

Problem: Farklı host'lar farklı tarih/saat formatları kullanıyor, bu da zamanlama, günlük kaydı ve ağ koordinasyonunu zorlaştırıyor.

Öneri: Tüm ağ host'larının iletişim ve koordinasyon için kullanması gereken tek tip bir gün ve saat belirtimi oluşturma.

---

İçindekiler

1. Problem Tanımı
2. Gereksinim Analizi
3. Önerilen Format
4. Kullanım Örnekleri
5. Uygulama Yönergeleri
6. Benimseme Stratejisi
7. Önem

---

Problem Tanımı

Mevcut Durum

ARPANET host'ları değişken tarih/saat temsilleriyle çalışıyordu:

Sonuçlar

1. Günlük Korelasyon: Host'lar arasında olayları eşleştirmek imkansız
2. Zamanlama: Zamana bağlı işlemleri koordine etmek zor
3. Saat Senkronizasyonu: Zaman doğrulaması için standart yok
4. Dosya Zaman Damgaları: Ağ genelinde tutarsız değişiklik zamanları
5. Hata Ayıklama: Ağ genelinde yürütme sırasını izlemek zor

---

Gereksinim Analizi

Temel Gereksinimler

Evrensel bir gün ve saat formatı şunlar olmalıdır:

Ek Hususlar

• Sıralanabilirlik: Leksikografik sıralamayı desteklemeli
• Uyumluluk: Mevcut günlük sistemleriyle çalışmalı
• Genişletilebilirlik: Gerekirse milisaniye veya mikrosaniyeye izin vermeli
• Uluslararasılaşma: Kültürden bağımsız olmalı

---

Önerilen Format

Önerilen Spesifikasyon

Seçenek 1: İnsan Tarafından Okunabilir Format

GG-AAA-YYYY SS:DD:SS [Z|+SS:DD|-SS:DD]

Örnek: 27-Ağu-1969 14:30:45 Z

Bileşenler:

• GG: Ayın günü (01-31)
• AAA: Üç harfli ay kısaltması (Oca, Şub, ..., Ara)
• YYYY: Dört haneli yıl (1969, 1970, vb.)
• SS:DD:SS: Saat, dakika, saniye (24 saat formatı)
• Saat Dilimi: UTC için Z, veya +/- fark

Seçenek 2: Sayısal Format

YYYY-AA-GG SS:DD:SS

Örnek: 1969-08-27 14:30:45

Avantajlar:

• Tamamen sayısal
• Leksikografik olarak sıralanabilir
• ISO standart hizalaması
• Uluslararası olarak belirsiz değil

Önerilen Seçim: Seçenek 2

Sayısal format için gerekçe:

1. Belirsiz olmayan tarih yorumlama
2. Basit dize karşılaştırmasıyla sıralanabilir
3. Çeviri gereksinimlerini minimize eder
4. Uluslararası standartlarla hizalanır

---

Kullanım Örnekleri

Ağ Mesajlarında

Mesaj: FILE_MODIFIED
Kaynak: UCLA-Host
Zaman Damgası: 1969-08-27 14:30:45
Dosya: /data/experiment.log
Boyut: 2048 bayt

Günlük Dosyalarında

1969-08-27 08:15:30 - SRI-Host'a bağlantı kuruldu
1969-08-27 08:15:45 - Dosya iletimi başladı
1969-08-27 08:16:02 - 512 bayt iletildi
1969-08-27 08:16:15 - Dosya iletimi tamamlandı
1969-08-27 08:16:20 - Bağlantı kapatıldı

Sistem Olaylarında

Olay Günlüğü:
1969-08-20 10:00:00 - Sistem başlatma
1969-08-20 10:05:30 - Ağ başlatma
1969-08-20 10:06:15 - SRI ile NCP el sıkışması
1969-08-27 14:30:00 - IMP istatistikleri toplandı

Zamanlanmış Görevlerde

Görev Programı:
- Günlük yedekleme: 1969-08-27 19:00:00
- Haftalık rapor: 1969-08-28 08:00:00
- Aylık arşiv: 1969-09-01 00:00:00

---

Uygulama Yönergeleri

Bireysel Host'lar İçin

Unix Sistemleri

Biçimlendirme için strftime("%Y-%m-%d %H:%M:%S") kullan:

time_t now = time(NULL);
struct tm *tm_info = localtime(&now);
char buffer[32];
strftime(buffer, sizeof(buffer), "%Y-%m-%d %H:%M:%S", tm_info);

Tenex Sistemleri

Yerel zaman temsilini standart formata dönüştür:

(CVTIM time-tuple "%Y-%m-%d %H:%M:%S")

Dosya Sistemleri

Zaman damgalarını açık saat dilimiyle sakla:

1969-08-27 14:30:45 UTC

Ağ İletişimi İçin

Ağ üzerinden zaman iletirken:

1. Her zaman UTC/Zulu zaman referanslarını kullan
2. Yerel zaman kullanılırsa mesaja saat dilimini dahil et
3. Alıcının dönüştürmesine izin vermek için saat dilimi alanı ekle

Gelecek Uyumluluk İçin

• İsteğe bağlı mikrosaniyeler için alan ayır (gelecek uzantı)
• Tarih ve saat arasında T veya boşluğa izin ver
• İsteğe bağlı saniye.milisaniye destekle

---

Benimseme Stratejisi

Aşamalı Uygulama

Faz 1: Ağ Koordinasyon Merkezi tarafından Benimseme

• NCL günlükleri standart format kullanır
• Dosya zaman damgaları standartlaştırılır
• Host yazılımı güncellenir

Faz 2: Host Uygulayıcıları tarafından Benimseme

• Unix/Tenex/diğer sistemler dönüştürme rutinleri ekler
• Dokümantasyon ve yönergeler yayınlanır
• Host'lar arası zaman damgası eşleştirmesi test edilir

Faz 3: Protokol Entegrasyonu

• Ağ Komutları zaman damgalarını içerir
• Mesaj başlıkları standartlaştırılır
• Hata günlüğü formatı kullanır

Faz 4: İzleme ve Doğrulama

• Tüm host'ların standardı kullandığını doğrula
• Eski uyumsuz sistemleri ele al
• Yeni protokol katmanlarına genişlet

---

Tarihsel Önem

RFC 16, ARPANET gelişimi sırasında standardizasyon ve birlikte çalışabilirlik hakkında önemli düşünceyi belgeler.

Modern Standartlar Üzerindeki Etki

1. Zaman Protokolleri: NTP'nin (Network Time Protocol) geliştirilmesine yol açtı
2. Standartlar: ISO 8601 (uluslararası tarih/saat standardı)
3. Günlük Kaydı: Syslog ve yapılandırılmış günlük formatları
4. API'ler: HTTP zaman damgası başlıkları benzer ilkeleri takip eder
5. Koordinasyon: Ağ genelinde dağıtık sistemler koordinasyonu

Öğrenilen Dersler

1. Standardizasyon önemlidir: Ortak formatlar ağ ölçeğinde sistemleri mümkün kılar
2. Basit kazanır: Açıkça tanımlanmış bir format uygulama karışıklığını önler
3. Birlikte çalışabilirlik: Paylaşılan standartlar heterojen sistemlerin birlikte çalışmasını sağlar
4. Öngörü: Erken standardizasyon daha sonraki yeniden çalışmayı önler

---

Önem

RFC 16, temel bir dağıtık sistem zorluğunu ele alır: bağımsız sistemler arasında ortak referans noktaları (zaman) oluşturma.

Öneri şunları etkiledi:

• Protokol tasarımı: Zaman damgalarının temel meta veri haline geldiği yer
• Ağ güvenilirliği: Zamana dayalı sıralama ve zaman aşımı işleme
• Sistem yönetimi: Günlük korelasyon ve denetim izleri
• Ağ işlemleri: İzleme ve sorun giderme

Bu görünüşte basit öneri, tüm modern dağıtık sistem altyapısının temelini oluşturacak ilkeleri belirledi.

---

University of California, Los Angeles (UCLA)

Network Working Group

Ağustos 1969