Hur förbereder jag mina webbsidor för att visa datum i olika internationella datumformat?
Webbplatsbesökare som kommer från olika lokaler kan förvirras av hur datum beskrivs. (Översättarens anmärkning: det svenska termen lokal används här som översättning av den engelska locale.) En lokal definierar användarens preferenser för användning av språk, datum, tid, valutor, mått, sortering, etc.) Formatet MM/DD/YY är specifikt för USA. I största delen av Europa används DD/MM/YY. I Japan används YY/MM/DD. De skiljetecken som används kan vara snedstreck, bindestreck eller punkt. I några lokaler används inledande nolla, i andra gör man inte så. Om en användare som kommer från Japan ser en amerikansk engelskspråkig webbsida, som hämtats från en webbplats i Tyskland, och som visar datum 03/04/02, hur tolkar då användaren detta datum?
Din första tanke kan vara att detta problem tas om hand genom lokalisering av webbsidan – dvs att översättaren ser till att det blir rätt. Motstå denna frestelse. Vill du verkligen hantera olika kopior av dokumentet för USA och för Storbritannien, som bara skiljer sig åt vad gäller datumformat? Du måste ändå kunna hantera flerspråkiga användare, som illustrerades i vårt exempel ovan.
Du har tre alternativ att välja mellan, där var och en har såväl fördelar som nackdelar:
ISO 8601 specificerar formatet YYYY-MM-DD. 2003-04-02 är tydligare än 03/04/02. (Vissa föredrar att anpassa ISO 8601 genom att använda en förkortning av månadsnamnet så att månaden blir tydligare, t.ex. 2003-Apr-02, men då är det inte längre lokalneutralt.)
Fördelar:
Nackdelar:
För att uppnå detta så kan du använda månadens namn (förkortat eller ej), och använda fyra siffror för alla Gregorianska årtal. Exempelvis, 2 april 2003.
Fördelar:
Nackdelar:
HTTP-huvudet "Accept-Language" anger egentligen bara användarens preferenser för språk, men används ofta för att bestämma lokalpreferenser.
Denna metod fungerar bra för dynamiskt skapade webbdokument, där datum hämtas från någon serverdatabas och läggs in i en webbsida, så länge som användarens förväntningar om datumformat är tydliga. Om det är lämpligt eller ej beror snarare på det språkliga kontextet än på inställningarna i användarens webbläsare. Till exempel:
Hur detta kan åstadkommas beror på din utvecklingsmiljö. Här är några pekare för vanliga utvecklingsmiljöer.
Anropa metoden getLocale i objekten ServletRequest eller HttpServletRequest.
Använd det resulterande objektet Locale för att anropa DateFormat.
Observera att formatet SHORT enbart använder siffror.
Om du vill ha ett otvetydigt format, använd då formatet LONG.
I några lokaler ger även formatet LONG enbart siffror.
Se även ICU4J eftersom den innehåller mer aktualiserad data (och mer funktionalitet) än JDK-rutinerna.
Använd Request.ServerVariables('HTTP_ACCEPT_LANGUAGE') för att få tag på användarens preferenser.
Parsa den första lokalen i listan av acceptabla lokaler.
Du måste själv hantera
avbildningen från alfabetisk
lokalkod till numerisk lokalidentifierare
("Locale Identifier").
Sätt Session.LCID till det returnerade värdet.
Anropa FormatDateTime för att formatera datum.
Använd vbLongDate för att undvika tvetydighet.
Det finns ingen perfekt lösning för detta problem. Utvärdera alternativen och välj det som bäst svarar mot dina preferenser och aktuellt sammanhang.
Om det är möjligt att användaren kan bli tveksam om hur visade datum skall förstås, så är det vanligen bäst att använda explicit månadsnamn och fyrsiffriga årtal för gregorianska datum, eller ange åtminstone i sidan hur datum skall förstås.
Datum kan omformateras med dynamiska metoder för att passa till sidans språkliga sammanhang.
Några har förespråkat att man ska skapa en <date>-tagg, som skulle visa datum i enlighet med den lokal som är angiven i webbläsaren. Detta skulle ge samma svårigheter som beskrevs för dynamiskt genererade datum med det japanska exemplet ovan. Det mest lämpliga formatet beror vanligen på sidans språkliga sammanhang, och inte på det verktyg som användaren använder.