Ö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