Tarih ve Saat Yerelleştirme: Formatlar, Saat Dilimleri ve B…

Tarih ve Saat Yerelleştirme: Formatlar, Saat Dilimleri ve Beraberinde Gelen Hatalar

Avustralya'daki kullanıcılara yanlış tarih gösteren bir özellik yayımladıysanız ya da UTC'yi kastederken yerel saat diliminde bir zaman depoladıysanız, tarih ve saat işlemenin ne kadar affetmez olduğunu zaten biliyorsunuzdur. Bunlar uç durumlar değil; bunlar olağan durumlar.

Tarih ve saat yerelleştirmesi iki ayrı zor problemin kesişiminde yer alır: uluslararasılaştırma (farklı formatlar, takvimler, diller) ve dağıtık sistemler (saat dilimleri, yaz saati geçişleri, saat sapması). Bunlardan birini yanlış yaparsanız kullanıcılar anlamsız veriler görür; ya da daha kötüsü, saatler veya günler kadar ince ama plausible görünen veriler görür.

Bu yazı tüm katmanları kapsar: tarihlerin nasıl depolanması, iletilmesi ve görüntülenmesi gerektiğini. JavaScript, Python ve Ruby'de çalışan kod örnekleri içerir ve ayrıntıları atlayan ekipleri yakalayan spesifik hatalara değinir.

Biçimlendirme Sorunu: AA/GG/YYYY - GG/AA/YYYY ve Diğerleri

Bir tarihi yazmanın evrensel olarak kabul görmüş tek bir yolu yoktur. Bu cümle tek başına sayısız kullanıcı karışıklığı biletinden sorumludur.

En yaygın çatışma, ABD formatı (AA/GG/YYYY) ile Avrupa/dünyanın büyük çoğunluğunun formatı (GG/AA/YYYY) arasındadır. 04/05/2024 tarihi ABD'de 5 Nisan, Almanya'da ise 4 Mayıs anlamına gelir. Kullanıcının yerel ayarını bilmeden yalnızca diziden hangisinin doğru olduğunu anlamanın yolu yoktur.

Bu sıralama çatışmasının ötesinde, formatlar daha da ayrışır:

Japonya, Çin, Kore: YYYY/AA/GG veya YYYY年MM月DD日
ISO 8601: YYYY-AA-GG (tek belirsizlik barındırmayan format; bu yüzden depolama ve API'ler için bunu kullanmalısınız)
Hindistan: GG-AA-YYYY, ancak çoğunlukla nokta veya eğik çizgiyle yazılır
İran, Afganistan, Etiyopya: Gregoryen tarihlerin farklı sıralamalarını değil, tamamen farklı takvimleri (Pers, Etiyopya) kullanır

Görüntüleme için kural şudur: asla bir tarih formatını sabit kodlamayın. Her zaman kullanıcının yerel ayarından türetin. Bu, yerelleştirme ile uluslararasılaştırma arasındaki daha geniş zorluğun yalnızca bir boyutudur — bu ayrım yalnızca tarih formatlarından çok daha fazlasını etkiler. Diller arası çoğullama kuralları, yerel ayara özgü davranışın dikkatli işlem gerektirdiği ilgili bir başka alandır.

ISO 8601: Depolama ve API'ler İçin Kullanmanız Gereken Tek Format

Tarihleri depoluyorsanız veya servisler arasında aktarıyorsanız, ISO 8601 kullanın. Her zaman. İstisna yok.

ISO 8601 tarihleri, tarihler için 2024-04-05 ve tarih-saatler için 2024-04-05T14:30:00Z şeklinde görünür. Bu formatı arka uç kullanımı için uygun kılan temel özellikler:

Belirsizlik barındırmaz: yerel ayara bağımlı sıralama yok
Sıralanabilir: sözlüksel sıralama kronolojik sıralamaya eşittir
Saat dilimi açık: Z son eki (veya +05:30 ofseti) saat dilimini değerin bir parçası yapar
Evrensel destek: her büyük programlama dili ek kütüphane olmadan ayrıştırabilir

Tarih işlemede en yaygın tek hata, veritabanında yerel tarih-saat dizisi depolamaktır. Bu dizi Frankfurt'taki bir sunucuda üretildiğinde bir şey ifade eder. New York'taki bir sunucuda okunduğunda başka bir şey ifade eder. Açık UTC ofseti ile ISO 8601 bu belirsizliği ortadan kaldırır.

# Python: Her zaman UTC'de depolayın, her zaman saat dilimi bilgisi ekleyin
from datetime import datetime, timezone

# YANLIŞ: naif datetime, saat dilimi bilgisi yok
bad = datetime.now()  # "2024-04-05 14:30:00" — yerel saat mi? UTC mi? bilinmez

# DOĞRU: saat dilimine duyarlı UTC datetime
good = datetime.now(timezone.utc)  # "2024-04-05T14:30:00+00:00"
good_str = good.isoformat()  # "2024-04-05T14:30:00+00:00"

// JavaScript: Serileştirme için ISO dizeleri kullanın
const now = new Date();

// YANLIŞ: yerel ayara bağımlı, taşınabilir değil
const bad = now.toLocaleDateString(); // "4/5/2024" (US), "05.04.2024" (DE)

// DOĞRU: ISO 8601, açık UTC
const good = now.toISOString(); // "2024-04-05T14:30:00.000Z"

# Ruby: UTC ve ISO 8601 kullanın
# YANLIŞ
Time.now.to_s  # "2024-04-05 14:30:00 +0200" — yerel saat dilimi sızıyor

# DOĞRU
Time.now.utc.iso8601  # "2024-04-05T12:30:00Z"

Saat Dilimleri: UTC'de Depolayın, Yerel Saatte Gösterin

Saat dilimi işlemenin yönetim ilkesi söylemesi kolay ama son teslim tarihi baskısı altında unutması kolaydır: UTC'de depolayın, kullanıcının yerel saatinde gösterin.

UTC bir saat dilimi değil, bir standarttır. Yaz saati uygulamasını gözlemlemez. Kaymaz. Bir UTC zaman damgası, Dünya'nın her yerinde tam olarak aynı şeyi ifade eden mutlak bir zaman noktasıdır.

UTC'de depoladığınızda ve kullanıcının saat dilimini bildiğinizde, her zaman doğru yerel saati hesaplayabilirsiniz. Saat dilimi olmadan yerel saati depoladığınızda, kurtaramayacağınız bilgileri kaybetmişsinizdir.

Kullanıcının saat dilimini nereden almalısınız? Kabaca güvenilirlik sırasına göre birkaç kaynak:

Açık kullanıcı tercihi profilinde saklanan (en doğru, kullanıcı kontrolünde)
Tarayıcı API: Intl.DateTimeFormat().resolvedOptions().timeZone IANA saat dilimi dizesini döndürür
IP coğrafi konumu (yaklaşık, mobil kullanıcılar için zayıf, VPN'lerde başarısız)

// Tarayıcıdan kullanıcı saat dilimini al
const userTimezone = Intl.DateTimeFormat().resolvedOptions().timeZone;
// örn., "America/New_York", "Europe/Berlin", "Asia/Kolkata"

Saat dilimini aldıktan sonra biçimlendirme mantığınıza aktarın. UTC zaman damgalarını yerel saate manuel olarak dönüştürmeye çalışmayın. DST geçişlerini anlayan yerleşik kütüphaneler kullanın.

Yaz Saati Uygulaması: Manuel Ofset Aritmetiği Neden Başarısız Olur

Yaz Saati Uygulaması (YSU), saat dilimi ofsetlerini asla sabit kodlamamanız gerektiğinin nedenidir.

"Almanya UTC+1'dir" yılın yarısında yanlıştır. Almanya kışın CET (UTC+1) ve yazın CEST (UTC+2) gözlemler. +1'i sabit kodlarsanız ve bir kullanıcı Mart'ta saat 10'da bir etkinlik oluşturursa, yaz geldiğinde depolanan ofsettiniz yanlış olur ve etkinlik yanlış saatte görünür.

Olson (IANA) saat dilimi veritabanı — America/New_York, Europe/Berlin, Asia/Kolkata gibi isimler — her saat dilimi için YSU geçişlerinin tam geçmiş ve gelecek programını içerir. Her platform onu taşır. Ham ofset değil, adlandırılmış saat dilimini kullanın.

Dikkat edilmesi gereken YSU geçiş hataları:

Belirsiz saat: Saatler geri döner, bu yüzden sabah 1:30 iki kez yaşanır. Hangi oluşum olduğu bilinmeden "1:30" belirsizdir.
Var olmayan saat: Saatler ileri gider, bu yüzden 2:30 mevcut değildir. Bazı ayrıştırıcılar sessizce ayarlama yapar.
Kaymış tekrar eden etkinlik: "Yerel saat 15:00"de haftalık tekrar eden bir etkinlik, YSU geçişinden sonra yerel saat 15:00'de kalmalıdır — bu da UTC saatinin bir saat değiştiği anlamına gelir.

// JavaScript: YSU'yu Intl API'nin sizin için yönetmesine izin verin
const formatter = new Intl.DateTimeFormat('de-DE', {
  timeZone: 'Europe/Berlin',
  hour: '2-digit',
  minute: '2-digit',
  day: '2-digit',
  month: '2-digit',
  year: 'numeric',
});

// Hem CET hem de CEST'te güvenli
const utcDate = new Date('2024-03-31T01:30:00Z'); // Avrupa'da YSU geçiş günü
console.log(formatter.format(utcDate)); // "31.03.2024, 03:30"

# Python: zoneinfo (Python 3.9+) veya pytz kullanın
from zoneinfo import ZoneInfo
from datetime import datetime

utc_time = datetime(2024, 3, 31, 1, 30, tzinfo=ZoneInfo("UTC"))
berlin_time = utc_time.astimezone(ZoneInfo("Europe/Berlin"))
print(berlin_time)  # 2024-03-31 03:30:00+02:00 — YSU duyarlı dönüşüm

# Ruby: Güvenilir YSU işleme için TZInfo gem'i kullanın
require 'tzinfo'

tz = TZInfo::Timezone.get('Europe/Berlin')
utc = Time.utc(2024, 3, 31, 1, 30)
local = tz.utc_to_local(utc)
# YSU'ya göre ayarlanmış saati doğru döndürür

JavaScript Intl.DateTimeFormat: Tarihleri Biçimlendirmenin Doğru Yolu

Intl.DateTimeFormat API'si her modern JavaScript çalışma zamanına yerleşiktir. Dış bağımlılıklar olmadan yerel ayara özgü biçimlendirmeyi, saat dilimi dönüşümünü ve takvim sistemlerini yönetir.

// Temel yerel ayar duyarlı tarih biçimlendirme
const date = new Date('2024-08-15T09:00:00Z');

// ABD İngilizcesi
new Intl.DateTimeFormat('en-US', { dateStyle: 'long' }).format(date);
// "August 15, 2024"

// Almanca
new Intl.DateTimeFormat('de-DE', { dateStyle: 'long' }).format(date);
// "15. August 2024"

// Japonca
new Intl.DateTimeFormat('ja-JP', { dateStyle: 'long' }).format(date);
// "2024年8月15日"

// Saat ve saat dilimiyle
new Intl.DateTimeFormat('en-GB', {
  dateStyle: 'full',
  timeStyle: 'short',
  timeZone: 'Europe/London',
}).format(date);
// "Thursday, 15 August 2024 at 10:00"

Göreceli zaman biçimlendirmesi (örn. "3 saat önce") Intl.RelativeTimeFormat kullanır:

const rtf = new Intl.RelativeTimeFormat('fr-FR', { numeric: 'auto' });

rtf.format(-1, 'day');   // "hier" (dün)
rtf.format(-3, 'hour');  // "il y a 3 heures"
rtf.format(2, 'week');   // "dans 2 semaines"

Intl.RelativeTimeFormat'ın değeri ve birimi hesaplamanızı gerektirdiğini unutmayın. Bir şeyin "dün" mü yoksa "3 gün önce" mi olduğunu sizin için belirlemez. date-fns veya Temporal (mevcut Date API'sinin halefi) gibi kütüphaneler bu mantığı Intl'nin üzerine katmanlar.

Python ve Ruby: Babel, strftime ve Sınırları

Python: Yerel Ayar Duyarlı Biçimlendirme için Babel

Python'daki standart kütüphane strftime yalnızca sistem yerel ayarı aracılığıyla yerel ayar duyarlı çıktı üretir; bu da üretim ortamlarında güvenilir değildir. Doğru i18n için Babel kullanın:

from babel.dates import format_date, format_datetime, format_time
from datetime import datetime, timezone

dt = datetime(2024, 8, 15, 9, 0, 0, tzinfo=timezone.utc)

# Farklı yerel ayarlar için biçimlendir
format_date(dt, locale='en_US')    # 'Aug 15, 2024'
format_date(dt, locale='de_DE')    # '15.08.2024'
format_date(dt, locale='ja_JP')    # '2024/08/15'
format_date(dt, format='long', locale='ar_SA')  # '١٥ أغسطس ٢٠٢٤'

# Saat dilimi dönüşümüyle
from babel.dates import get_timezone
format_datetime(
    dt,
    format='full',
    tzinfo=get_timezone('America/New_York'),
    locale='en_US'
)
# 'Thursday, August 15, 2024 at 5:00:00 AM Eastern Daylight Time'

Ruby: strftime Yerel Ayar Körüdür

Ruby'nin yerleşik strftime'ı yerel ayar duyarlı değildir. Time.now.strftime('%B %d, %Y') uygulama yerel ayarından bağımsız olarak her zaman İngilizce ay adları üretir. Yerel ayar duyarlı çıktı için, yerel ayara özgü format dizeleriyle i18n gem'ini (Rails'de standart) veya CLDR tabanlı biçimlendirme için twitter_cldr'yi kullanın:

require 'twitter_cldr'

date = DateTime.new(2024, 8, 15, 9, 0, 0)

# İngilizce
date.localize(:en).to_long_s  # "August 15, 2024"

# Almanca
date.localize(:de).to_long_s  # "15. August 2024"

# Japonca
date.localize(:ja).to_long_s  # "2024年8月15日"

# Göreceli zaman
time_ago = 3.hours.ago
time_ago.localize(:fr).ago.to_s  # "il y a 3 heures"

Rails uygulamalarında, yerel YAML dosyalarıyla I18n.l(date, format: :long) geleneksel yaklaşımdır; ancak bu YAML dosyalarındaki format dizeleri yine de her dil için manuel yerelleştirme gerektirir.

Üretim Hatalarına Neden Olan Yaygın Hatalar

1. Veritabanında Yerel Saati Depolamak

-- YANLIŞ: Bu hangi saat diliminde?
created_at DATETIME DEFAULT NOW()

-- DOĞRU: Her zaman UTC depolayın
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() AT TIME ZONE 'UTC'

Veri tabanı sütun türünüz saat dilimi farkındalığı olmayan DATETIME ise, zaten bilgi kaybettiniz. TIMESTAMP WITH TIME ZONE'a (veya eşdeğerine) geçin ve uygulama katmanınızın her zaman UTC yazdığından emin olun.

2. ISO Olmayan Dizeleri Ayrıştırmak için JavaScript Date() Kullanmak

// YANLIŞ: ISO olmayan dizeler için ayrıştırma davranışı uygulamaya göre tanımlanmıştır
new Date('05/04/2024')  // 4 Mayıs mı, 5 Nisan mı? Ortam yerel ayarına bağlı

// DOĞRU: Yalnızca ISO 8601 dizelerini ayrıştırın veya bir kütüphane kullanın
new Date('2024-05-04')  // Her zaman 4 Mayıs 2024

3. Sunucu Saat Diliminin UTC Olduğunu Varsaymak

Birçok bulut ortamı varsayılan olarak UTC kullanır, ancak birçoğu kullanmaz. TZ ortam değişkenlerini kontrol etmeden new Date()'in UTC döndürdüğünü varsayan kod, farklı dağıtımlarda farklı davranır.

// YANLIŞ: Sunucunun UTC olduğunu varsayar
const today = new Date().toISOString().split('T')[0];

// DOĞRU: Ne hesapladığınız konusunda açık olun
const todayUTC = new Date().toISOString().split('T')[0]; // Bu toISOString üzerinden UTC'dir
// Ancak "kullanıcının saat diliminde bugünü" istiyorsanız:
const todayLocal = new Intl.DateTimeFormat('en-CA', {
  timeZone: userTimezone
}).format(new Date()); // "2024-08-15"

4. Gece Yarısı Güvenli Bir Varsayılan Saat Değildir

Belirli bir tarihte gece yarısı UTC'de bir etkinlik oluşturursanız, bu etkinlik UTC-5 ile UTC-12 arasındaki kullanıcılar için bir önceki güne aittir. "Tüm gün etkinlikleri" yalnızca bir tarih (YYYY-AA-GG) saklamalı, tarih-saat değil.

5. Ofseti Saat Dilimi Olarak Ele Almak

+05:30 bir ofset, bir saat dilimi değildir. Hindistan (Asia/Kolkata) her zaman UTC+5:30'dur ve YSU gözlemlemez, bu yüzden bu durumda ayrım zararsızdır. Ancak +10:00 için bu Australia/Sydney (YSU gözlemler) veya Pacific/Port_Moresby (gözlemlemez) olabilir. Ham ofsetin yanında veya yerine her zaman IANA saat dilimi adını saklayın.

Web Uygulamalarında Kullanıcı Saat Dilimi Tercihlerini Yönetmek

Eksiksiz bir uygulama üç şeye ihtiyaç duyar:

Kayıt sırasında saat dilimini tespit edin veya toplayın: Varsayılan olarak tarayıcı API'sini kullanın, kullanıcıların ayarlarda geçersiz kılmasına izin verin.
IANA saat dilimi dizesini kullanıcı profilinde saklayın: Ofset değil, şehir adı değil.
Depolama zamanında değil, render zamanında uygulayın: Zaman damgaları veritabanında UTC olarak kalır; dönüşüm, kullanıcıya görüntülenirken uygulama katmanında gerçekleşir.

// Ön yüzde: tespit edin ve arka uca gönderin
const detectedTimezone = Intl.DateTimeFormat().resolvedOptions().timeZone;

// Kayıt veya profil kaydetme sırasında:
await api.updateProfile({ timezone: detectedTimezone });

// API'den alınan tarihleri render ederken:
function formatEventTime(isoString, userTimezone, locale) {
  return new Intl.DateTimeFormat(locale, {
    timeZone: userTimezone,
    dateStyle: 'medium',
    timeStyle: 'short',
  }).format(new Date(isoString));
}

// Kullanım
formatEventTime('2024-08-15T14:30:00Z', 'Asia/Tokyo', 'ja-JP');
// "2024/08/15 23:30"

Sunucu tarafında, "bir kullanıcı için belirli bir takvim gününündeki tüm etkinlikler" yorumlamanız gerektiğinde, onların "bugününü" bir UTC aralığına dönüştürmeniz gerekir:

from datetime import datetime
from zoneinfo import ZoneInfo

def get_day_utc_range(date_str: str, user_timezone: str):
    """Yerel bir tarihi UTC datetime aralığına dönüştürün."""
    tz = ZoneInfo(user_timezone)
    local_start = datetime.fromisoformat(f"{date_str}T00:00:00").replace(tzinfo=tz)
    local_end = datetime.fromisoformat(f"{date_str}T23:59:59").replace(tzinfo=tz)
    utc_start = local_start.astimezone(ZoneInfo("UTC"))
    utc_end = local_end.astimezone(ZoneInfo("UTC"))
    return utc_start, utc_end

# Tokyo'daki bir kullanıcı için "bugün", New York'taki bir kullanıcıdan farklı bir UTC aralığıdır
start, end = get_day_utc_range("2024-08-15", "Asia/Tokyo")
# Sorgu: WHERE created_at BETWEEN start AND end

Tarih Yerelleştirmesini Test Etmek

Tarih yerelleştirme hataları geliştirmede çoğunlukla görünmezdir çünkü geliştiriciler ve CI sunucuları aynı saat diliminde olmaya meyillidir. Testlerin açıkça şunları kapsaması gerekir:

Birden fazla yerel ayar: en azından en-US, de-DE, ja-JP, ar-SA (RTL + farklı rakamlar) test edin
YSU geçiş tarihleri: Mart ve Kasım (kuzey yarımküre), Eylül ve Nisan (güney yarımküre)
Saat dilimi uç durumları: UTC-12, UTC+14, Hindistan (UTC+5:30), Nepal (UTC+5:45) ile test edin
Yıl/ay sınırları: Saat dilimlerinde 31 Aralık'tan 1 Ocak'a geçiş

// Jest: tutarsızlığı önlemek için sabit tarihlerle test edin
describe('formatEventTime', () => {
  const testCases = [
    {
      input: '2024-03-31T01:30:00Z', // Avrupa'da YSU geçişi
      timezone: 'Europe/Berlin',
      locale: 'de-DE',
      expected: '31.03.2024, 03:30', // 03:30'a ileri gider
    },
    {
      input: '2024-08-15T14:30:00Z',
      timezone: 'Asia/Kolkata',
      locale: 'hi-IN',
      expected: '15/8/2024, 8:00 pm', // UTC+5:30
    },
  ];

  test.each(testCases)('$locale yerel ayarında $timezone için doğru biçimlendirir', ({ input, timezone, locale, expected }) => {
    expect(formatEventTime(input, timezone, locale)).toBe(expected);
  });
});

CI ortamları için, testlerin sunucunun yerel saat dilimine bağımlı olmasını önlemek amacıyla TZ ortam değişkenini açıkça UTC olarak ayarlayın:

TZ=UTC npx jest

Tarih işleme aynı zamanda global ürünleri zorlayan diğer yerel ayara özgü kurallarla da yakından bağlantılıdır. Birden fazla pazar için geliştiriyorsanız, diller arası çoğullama kuralları ve hreflang etiketleriyle doğru i18n SEO uygulaması saat dilimi işlemenin yanında incelemeye değer ilgili alanlardır. Uluslararasılaştırma konusunda ciddi olan ekipler ayrıca yalnızca tarih formatlarının ötesine geçen kapsamlı i18n test stratejilerine de göz atmalıdır.

Better i18n Nereye Uyuyor

Manuel tarih biçimlendirmesi çözülebilir — Intl API ve Babel gibi kütüphaneler render katmanını iyi bir şekilde yönetir. Daha zor problem ölçektir: 20 yerel ayarı destekleyen bir uygulamanız olduğunda, tarih formatı tercihlerinin her bileşen, her e-posta şablonu ve her dışa aktarma genelinde tutarlı olması gerekir. Bu tutarlılık ekipler büyüdükçe bozulur.

Better i18n, uygulama kodunuzun her bileşende Intl seçeneklerini sabit kodlamak yerine yerel ayar duyarlı format anahtarlarına başvurmasına izin vererek bunu ele alır. Bir yerel ayar için bir formatın değişmesi gerektiğinde — diyelim ki Alman kullanıcılarınızın farklı bir tarih stilini tercih ettiğini keşfettiniz — bileşen dosyaları arasında arama yapmak yerine tek bir yerde güncelleme yaparsınız.

React uygulamaları için özellikler sayfası, yerel ayar bağlamını tarih biçimlendirmeyle birleştiren entegrasyonları kapsar; böylece bileşenler, her bileşenin kendi Intl.DateTimeFormat örneğini yönetmesine gerek kalmadan tarihleri her zaman aktif yerel ayarın tercih ettiği formatta render eder.

Özellikler sayfası, yerel ayar verilerinin CDN dağıtımını kapsar; bu, tarih biçimlendirme için önemlidir çünkü tüm yerel ayarlar için tam CLDR veri seti büyüktür. Yerel ayar verilerini hepsini bir arada paketlemek yerine talep üzerine lazy-load etmek, doğruluktan ödün vermeden başlangıç sayfa ağırlıklarını düşük tutar.

Özet

Tarih ve saat yerelleştirmesi kozmetik bir sorun değildir. Ürettiği hatalar doğruluk hatalarıdır: yanlış günde etkinlikler, YSU'dan sonra kayan zaman damgaları, farklı bölgelerdeki kullanıcılar için farklı anlamlar ifade eden tarihler.

Çoğu sorunu önleyen pratikler:

Her yerde ISO 8601 UTC depolayın ve iletin: veritabanları, API'ler, günlükler
Ham ofsetler değil, kullanıcı kayıtlarının yanında IANA saat dilimi adlarını saklayın (örn. America/New_York)
Manuel format dizeleri yerine JavaScript'te Intl.DateTimeFormat kullanın
Arka uç kodunda yerel ayar duyarlı biçimlendirme için Babel (Python) veya twitter_cldr (Ruby) kullanın
Saat dilimi ofsetlerini asla sabit kodlamayın — çalışma zamanınızın standart kütüphanesi aracılığıyla IANA veritabanını kullanın
YSU geçiş tarihlerinde, birden fazla saat diliminde ve birden fazla yerel ayarda açıkça test edin

Depolama ve iletim katmanları büyük ölçüde dilden bağımsızdır: ISO 8601 ve UTC her yerde çalışır. Görüntüleme katmanı, yerel ayara özgü mantığın yaşadığı yerdir ve araçlar ile kütüphanelerin en fazla zaman kazandırdığı yer burasıdır. Tarih/saat işlemedeki sağlam bir temel, global içerik yerelleştirmesinin daha geniş disiplininin bir parçasıdır — ürününüzün her yönünü hizmet verdiğiniz her pazara yerele özgü hissettirmek.

Uygulamanızı better-i18n ile Küreselleştirin

better-i18n, yapay zeka destekli çevirileri, git'e özgü iş akışlarını ve küresel CDN dağıtımını tek bir geliştirici odaklı platformda birleştirir. Elektronik tablolar yönetmeyi bırakın ve her dilde göndermeye başlayın.

Ücretsiz başlayın → · Özellikleri keşfedin · Belgeleri okuyun

Tarih ve Saat Yerelleştirme: Formatlar, Saat Dilimleri ve Beraberinde Gelen Hatalar