On Thu, Apr 03, 2003 at 03:19:56PM +0200, Petter Reinholdtsen wrote:

[Keld Jørn Simonsen]

...

Jeg er naturligvis interessert. Det ville være greit om andre også var med.

OK, det blir visst bare oss to. Jeg foreslår at vi flytter diskusjonen om detaljene til i18n-no@lister.ping.uio.no.

Hmm, kan jeg være med der?

Jeg har sett på no_NO og nn_NO i CVSen til GNU libc, og det er mye galt der.

• 1 myntenhet skal skrives ut 'kr 1', ikke 'kr1' på norsk.

enig

• Uka begynner på mandag, ikke på søndag.

enig

• Forkortelsene på ukedager og måneder er feil.

Jeg vet ikke om det er riktig. Jeg tror det er noe som heter "UNIX-format" - også på norsk, og der benytter man tre bokstaver til å skrive ukedag. Men som du vet er jeg dansk, og jeg lar gjerne deg bestemme.

• Datoformatene er feil. Jeg er usikker på hva som er riktig.

Hmm, må jeg se på.

• Sortering på nynorsk er feil. Jeg er usikker på noen av randbetingelsene for sortering, men det er helt sikkert at 'aa' og 'å' skal sorteres bak 'ø' på norsk.

Jeg kan også koordinere lite med NTS.

• Tusenskilletegn er feil på nynorsk.

hva skal den være?

Er det noe jeg har glemt?

Jeg trenger dokumentasjon på hvordan locale-filer skal se ut. Jeg ser at det er flere felter som ikke er fyllt ut i de norske locale-filene.

Det følger i store trekk ISO TR 14652, se på http://www.dkuug.dk/jtc1/sc22/wg20

Jeg tror dessuten at filene bør reorganiseres slik at felles oppsett ligger i en fil, og spesielt oppsett ligger i de respektive locale-filene.

Ja, greit.

Keld

On Thu, Apr 03, 2003 at 04:38:34PM +0200, Petter Reinholdtsen wrote:

[Keld Jørn Simonsen]

...

...

• Forkortelsene på ukedager og måneder er feil.

Jeg vet ikke om det er riktig. Jeg tror det er noe som heter "UNIX-format" - også på norsk, og der benytter man tre bokstaver til å skrive ukedag. Men som du vet er jeg dansk, og jeg lar gjerne deg bestemme.

...

• Datoformatene er feil. Jeg er usikker på hva som er riktig.

Hmm, må jeg se på.

Disse to henger i hop. Men jeg tror språkrådet er en like god kilde som de fleste andre når det gjelder forkortelser av dager og måneder. URL:http://bugs.skolelinux.no/show_bug.cgi?id=102 har link til URL:http://www.sprakrad.no/oss.htm#maaned som forteller følgende:

Alle månedsforkortingene er på tre bokstaver pluss punktum. Mars, april, mai, juni og juli forkortes ikke. Dagene forkortes med to bokstaver pluss punktum.

Det vil ikke fungere. Disse datoformatene skal ha ens lengde. De optreder i fillister, i logger mm. Det vil ikke se pent ut hvis de ikke har samme lengde. "april" er på 5 bokstaver.

Nå gir 'LANG=no_NO date; LANG=nn_NO date' følgende output:

tor apr 3 16:33:35 CEST 2003 to apr 3 16:33:35 CEST 2003

Jeg tror dette bør skrives slik både på bokmål og nynorsk:

to. 3. april 16:33:35 CEST 2003

En annen formattering av datoer som er mer ødelagt er denne:

% LANG=no_NO date '+%c'; LANG=nn_NO date '+%c' tor 03-04-2003 16:34:50 CEST 03. apr 2003 kl 16.34 CEST

Jeg tror ingen av disse er riktig, selv om nynorsk-versjonen ser mer riktig ut enn bokmålsutgaven. '03-04-2003' burde helt klart vært '2003-04-03', men jeg er ikke overbevist om at den formatteringen bør brukes der i det hele tatt. Hva synes du?

jeg synes man ska bruke 2003-04-03 16:34 Det kan sorteres, og da er man fri for allt om forkortelser.

Og jeg synes man ska bruke ":" i tiden, for at unngå alle missforståelser om desimalt.

En tredje formattering er denne:

$ LANG=no_NO date '+%x'; LANG=nn_NO date '+%x' 03-04-2003 03. apr 2003

En fjerde formattering er denne:

LANG=no_NO date '+%X'; LANG=nn_NO date '+%X' 16:37:16 kl 16.37 CEST

Jeg tror bokmålsformatet er riktig her.

...

...

• Sortering på nynorsk er feil. Jeg er usikker på noen av randbetingelsene for sortering, men det er helt sikkert at 'aa' og 'å' skal sorteres bak 'ø' på norsk.

Jeg kan også koordinere lite med NTS.

Ja takk. Vi trenger en korrekt sortert eksempelfil for å sjekke at sortering av alle ASCII-tegn og endel annet blir riktig sortert på norsk.

...

...

• Tusenskilletegn er feil på nynorsk.

hva skal den være?

Jeg mener korrekt formattering på norsk er '1.100.456,50'. Slik blir det formattert med no_NO, mens nn_NO formaterer det med mellomrom: '1 100 456,50'.

jeg er enig her. Det er mye sværere å lese tallene med blanke, man tror at det er tale om flere tal. Og især hvis man faktisk har flere tal, så er det uhyggelig svært å se hvilke tal det er.

...

Det følger i store trekk ISO TR 14652, se på http://www.dkuug.dk/jtc1/sc22/wg20

Takk, jeg skal lese meg opp på det.

Hilsen keld

[Kjetil Torgrim Homme]

"jan." "feb." "mars" "apr." "mai " "juni" "juli" "aug." "sep." "okt." "nov." "des."

det einaste som er litt rart her er mai.

Ja, kanskje det er en god ide. Men det er i strid med anbefalingen fra språkrådet. Hvor viktig er det at vi følger dem?

må rekkefylgja vere slik? eg har alltid synest at det er rart at årstalet er skilt frå datoen.

Nei, vi kan velge rekkefølgen selv.

to. 3. april 2003 16.33.35 CEST

Jeg liker mer

to. 3. april 2003 16:33:35 CEST

Jeg liker kolon som skilletegn i klokkeslett. Det har med at jeg liker ISO-standarden for dato- og klokkeslettangivelser.

heiter det forresten CEST på norsk?

Aner ikke. Har vi norske tidssone-forkortelser? Jeg har aldri sett noen andre enn de engelske.

http://www.sprakrad.no/oss.htm#dato http://www.sprakrad.no/oss.htm#klokke

eg stemmer for

03.04.2003 16.34.50 CEST

Hm. Det underliggende spørsmålet er om vi skal følge Norsk Standardiseringsforbund eller språkrådet når disse ikke er enige. Svaret bør antagelig vurderes ut fra hvordan resultatet fra locale-settingene skal brukes. Skal resultatet kun vises fram, kun behandles maskinelt, eller begge deler. Jeg vet ikke.

Språkrådet har jo den fordelen at deres regler ligger tilgjengelig på web. NSF ser ut til å holde sin informasjon mer skjult.

Når det gjelder datoer, så har jeg mest sans for 2003-04-03 da det forenkler maskinell behandling og reduserer muligheten for misforståelser på tvers av landegrensene. Jeg hadde dog foretrukket at vi kunne fulgt noen offisielle standarder i stedet for å bruke min magefølelse når locale-verdiene skal fylles inn.

såg at eksempelfila du sendte tidlagere inneheldt det umoglege ordet "Haag". bortsett frå det, såg ho grei ut.

Det er vel ikke umulig det. Noen kan ha det som etternavn, eller det kan være et sted i utlandet som heter det. Bokstavsekvensen må jo ha en posisjon i en sortert liste også på norsk.

båe delar er korrekt, men det er meir praktisk med punktum som tusenskiljeteikn, ja.

Har du noen kilder på at begge er korrekt?

[Keld Jørn Simonsen]:

On Sat, Apr 05, 2003 at 12:03:04AM +0200, Petter Reinholdtsen wrote:

eg fekk ikkje meldinga til Petter.

...

to. 3. april 2003 16:33:35 CEST

Jeg liker kolon som skilletegn i klokkeslett. Det har med at jeg liker ISO-standarden for dato- og klokkeslettangivelser.

du er infisert av klokker og duppedittar som brukar kolon pga. dei er laga for den amerikanske marknaden :-)

hva med: torsdag den 3. april 2003 16:33:27 CEST Er ikke det det foretrukne lange formatet?

frykteleg langt, er det ikkje? forresten ville eg endra månadsnamnet til kortform også.

to. 3. apr. 2003 16.33.35 CEST

...

...

http://www.sprakrad.no/oss.htm#dato http://www.sprakrad.no/oss.htm#klokke

eg stemmer for

03.04.2003 16.34.50 CEST

Hm. Det underliggende spørsmålet er om vi skal følge Norsk Standardiseringsforbund eller språkrådet når disse ikke er enige. Svaret bør antagelig vurderes ut fra hvordan resultatet fra locale-settingene skal brukes. Skal resultatet kun vises fram, kun behandles maskinelt, eller begge deler. Jeg vet ikke.

mange steder benyttes det utskrivne igjen, f. eks. i logger, eller fillister, som brukes av ftp...

dei fleste loggfiler brukar ikkje locale-spesifikke datoformat, med god grunn.

å køyre ftp-daemon i eit anna locale enn en_US/POSIX/C vil føre til at svært mange klientar vil brekke, uansett korleis ein vrir og vender på det.

det viktigaste er at formatet ser naturleg ut for ein vanleg norsk brukar utan tidlegare kjennskap til engelsk eller Unix.

...

Språkrådet har jo den fordelen at deres regler ligger tilgjengelig på web. NSF ser ut til å holde sin informasjon mer skjult.

http://std.dkuug.dk/cultreg/registrations/narrative/nb_NO,_4.5 er offisiel fra Norsk Teknologi Senter (NTS). Den beskriver faktisk hva som det skal være med i et locale, og det var meningen med den. Det er så feil i den - men det kan rettes. Som det ligger på webben er det en del av en ISO standard (ISO 15897).

mykje bra info, der. fann ikkje så mykje å pirke på, Clause 16 er irrelevant for dette ;)

...

Når det gjelder datoer, så har jeg mest sans for 2003-04-03 da det forenkler maskinell behandling og reduserer muligheten for misforståelser på tvers av landegrensene. Jeg hadde dog foretrukket at vi kunne fulgt noen offisielle standarder i stedet for å bruke min magefølelse når locale-verdiene skal fylles inn.

NS-ISO 8601 er offisiel norsk standard (NS) og gir det velkjente 2003-04-03 formatet.

eg brukar dette formatet sjølv, men merkar godt at _ingen_ norske papirskjema er laga for det. det vert anten trangt, eller ein vert eksplisitt tvinga til å fylle inn annleis. det er nok berre spesielt interesserte datafolk som ser den fantastiske fordelen framfor tradisjonelle dd.mm.yy

...

...

såg at eksempelfila du sendte tidlagere inneheldt det umoglege ordet "Haag". bortsett frå det, såg ho grei ut.

Det er vel ikke umulig det. Noen kan ha det som etternavn, eller det kan være et sted i utlandet som heter det. Bokstavsekvensen må jo ha en posisjon i en sortert liste også på norsk.

det umoglege er at sorteringsalgoritma ikkje kan ha ei diger ordliste som seier at "haag" skal sorterast som "haag", medan "haakon" skal sorterast som "håkon".

Jeg tror vi må være praktiske og se hvad som er det mest vanlige i Norge, og jeg tror at det er at "aa" er det samme som å.

ja.

[Kjartan Maraas]:

Jeg har akkurat gått gjennom størsteparten av GNOME og endret alle klokkeslett fra å bruke kolon til punktum.

eit kraftig innlegg i debatten :-)

Enig med Kjetil her også. Jeg tror det eneste jeg reagerer på er tobokstavsforkortelser for dagnavn, men det kan hende at jeg kan venne meg til det :-)

eg også synest det er uvant med "må.", "ty.", "on." etc, og ville heller hatt "mån", "tys", "ons", "tors", "fre", "laur", "søn" -- men problemet er at ein då får varierande lengde på strengen. på bokmål går det litt greiare, men "tor" er også uvant. så det verkar som om to bokstavar er eit grei løysing.

Laurdag 5. april 2003 10:49 skreiv Petter Reinholdtsen:

Jeg har forsøkt å samle kommentarene, URLene og forslagene som har gått på lista i en webside. Jeg vil sette pris på om flere bidrar med tekst der. Sjekk URL:http://i18n.skolelinux.no/localeoppsett.html.

Eg har for referansen sin del lagt inn Microsoft sitt oppsett (frå Windows XP):

Tal: 123 456 789,00 Valuta: kr 123 456 789,00 Klokkeslett: 11:06:38 Kort dato: 07.04.2003 Lang dato: 7. april 2003

Dette oppfattar eg som veldig naturlege og greie format. Alt er i samsvar med Språkrådet sine tilrådingar, bortsett frå klokkeslettet. Frå eit teknisk synspunkt er det veldig greitt at klokkeslettet brukar kolon, for å skilja det frå datoar. Reknearket i OpenOffice.org har til dømes ein funksjon som automatisk kjenner att datoar og klokkeslett. Den fungerer ikkje dersom begge brukar same formatet.

Med helsing, Gaute Hvoslef Kvalnes

On Sat, Apr 05, 2003 at 09:44:55AM +0200, Karl Ove Hufthammer wrote:

Keld Jørn Simonsen keld@dkuug.dk skreiv i innlegget news:20030404230512.GA24257@rap.rap.dk:

...

Jeg tror vi må være praktiske og se hvad som er det mest vanlige i Norge, og jeg tror at det er at "aa" er det samme som å.

Eg vil på det sterkaste fråråda å sortera «aa» maskinelt som «å».

Hvorfor det? Dette er vel hovedreglen på norsk.

Hilsn keld

[Keld Jørn Simonsen]

http://std.dkuug.dk/cultreg/registrations/narrative/nb_NO,_4.5 er offisiel fra Norsk Teknologi Senter (NTS). Den beskriver faktisk hva som det skal være med i et locale, og det var meningen med den. Det er så feil i den - men det kan rettes. Som det ligger på webben er det en del av en ISO standard (ISO 15897).

Dokumentet mangler informasjon om hvor en skal ta kontakt hvis en har korreksjoner til dokumentet.

Jeg finner følgende:

Clause 3: Numeric formatting

The decimal separator is COMMA <,> For display of numbers in applications there is no use of a thousands separator, and thus no grouping for large numbers.

Jeg mener dette er feil. Språkrådet hevder at mellomrom brukes som skilletegn mellom grupper av tre siffer (Kilde URL:http://www.sprakrad.no/tall.htm), og jeg har ellers sett punktum brukt som skilletegn. Det er i alle fall helt sikkert at norsk grupperer sifrene tre og tre. Det hadde vært fint om Språkrådet og Norsk Standardiseringsforbund/Norsk Teknologi Senter kunne bli enige om hvordan dette skal være på norsk.

Jeg er for øvrig overbevist om at tall og beløp skal ha samme gruppering og skilletegn.

* Keld Jørn Simonsen keld@dkuug.dk [030407 10:54]:

...

Jeg mener dette er feil. Språkrådet hevder at mellomrom brukes som skilletegn mellom grupper av tre siffer (Kilde URL:http://www.sprakrad.no/tall.htm), og jeg har ellers sett punktum brukt som skilletegn. Det er i alle fall helt sikkert at norsk grupperer sifrene tre og tre. Det hadde vært fint om Språkrådet og Norsk Standardiseringsforbund/Norsk Teknologi Senter kunne bli enige om hvordan dette skal være på norsk.

Jeg er for øvrig overbevist om at tall og beløp skal ha samme gruppering og skilletegn.

Problemet er når du skal innlese tallene igjen. Så er det ofte et problem hvis det finnes tusinadskiller i tallene. Tenk på en større utskrift med en masse tal. I vanlige utskrifter med en mengde tal f.eks i vitenskapelige beregninger vil man nok ikke ha tusindadskiller.

Tusenskilletegn brukes jo først og fremst for presentasjon, og jeg vil påstå at i en vanlig utskrift med en mengde tall er det desto større behov for tusenskilletegn. Innlesing av tallene (maskinelt) bør selvsagt gjøres fra en datafil, ikke en presentasjonsfil. Det er ellers relativt enkelt å lese inn tall ut ifra et hvilket som helst locale vha localeconv dersom dette skulle være nødvendig.

Det er ellers interessant å se at språkrådet har valgt mellomrom som tusenskilletegn, mens f.eks. bankvesenet ser ut til å være ganske standardisert på punktum som skilletegn (både i beløp og i kontonummer (her er det dog ikke snakk om tusenskilletegn)).

Eivind

On Sat, Apr 05, 2003 at 10:07:57PM +0200, Petter Reinholdtsen wrote:

[Keld Jørn Simonsen]

...

http://std.dkuug.dk/cultreg/registrations/narrative/nb_NO,_4.5

Det er en beskrivelse av de enkelte paragraffer i dette, og vi kigger på denne beskrivelsen i arbeidsgruppa. Vi er åpne for kommentarer om forbedringer til teksten, som kommer her:

Contents of a Narrative Cultural Specification

The contents of the Narrative Cultural Specification is described in some detail in the following. it builds on information from the POSIX Shell and Utilities standard (ISO/IEC 9945-2) and the Nordic Cultural Requirements on Information Technology Summary Report. Clauses 1 to 6 are related to POSIX and the narrative description should be accompanied by a corresponding POSIX Locale specification. If a POSIX locale is submitted, it is desirable that it be accompanied by a related narrative cultural specification. Clause 7 to 32 are to provide information, which is not presently expressible in POSIX notation. Examples of Narrative Cultural Specifications are given in annex D.

Clause 1: Alphanumeric deterministic ordering

Here the specification of a national standard for ordering should be listed. If there are more standards, or options for a standard, there should be one POSIX specification for each of the standards or options. A European Multilingual Ordering standard such as ENV 13710, or other international standards, already in this registry, could be referenced and possible deviations, if any, could be described. Issues to cover may be: are there any letters that are sorted differently from other languages, are capital letters sorted before small letters, are there a specific ordering of accents, in which order should different scripts be, do some characters sort equally at first and then when the whole string is otherwise considerered equal, should they then be sorted differently at other levels? Does the language require reordering of some characters before collation weighting (e.g. Thai)? Does the language sort on a syllabic basis, rather than merely letter_by_letter (e.g. Burmese)? Does the language make use of ideographs, and if so, how are they handled with respect to other characters? If aspects of the ordering for the language extend beyond what a POSIX specification can handle, then details can be described in Clause 10. This is a POSIX category.

Clause 2: Classification of characters

The POSIX standard allows descriptions of what is alphabetic characters, capital and small letters, digits, hexadecimal digits, punctuation characters, spaces, graphical characters and control characters. This is a POSIX category.

Clause 3: Numeric formatting

Here it is described how numbers are keyed in and formatted, including the format of the decimal point and the thousands separator. This is a POSIX category.

Clause 4: Monetary formatting

Here formatting rules for monetary amounts, as well as local and international currency symbols according to ISO 4217, are described, as well as the relation between the amount, a sign and the currency symbol. This is a POSIX category.

Clause 5: Date and time conventions

Various names for days and months are given, together with formats for writing date and time. Things to consider are: do day and month names start with a capital letter or a small letter? Are there well recognized abbreviations for the day and month names? Is ISO 8601 formatting widespread? As the date formats are for use in POSIX, for example when listing files, consideration should be given to possible POSIX conventions in the culture. This is a POSIX category.

Clause 6: Affirmative and negative answers

Here the short notation for "yes" and "no" answers in the language can be specified. If the culture has strong relations to several languages, for example in a multilingual country, it should be permitted to answer in any of the languages. As English is widely used in many cultures, allowing responses in the English language should be considered. This is a POSIX category.

The rest of the clauses are not directly related to POSIX Locales:

Clause 7: National or cultural Information Technology terminology

Here terminology for a language or culture can be listed, for example a translation of ISO terminology for Information Technologies.

Clause 8: National or cultural profiles of standards

Here profiles of standards can be listed, for example, OSI national profiles, or profiles of the POSIX standards. See the POSIX ISO/IEC 9945-2 standard for an example.

Clause 9: Character set considerations

Here it can be described how characters are used in the culture, for example: - which characters are necessary to write a particular language, - which characters are used to give further precision in the language, - which characters are usually used in newspapers and books for writing of names and places, - which characters are used for historic writing of the language, - and which characters are used for other purposes.

This clause may also be used to specify which coded character sets are common in the culture and what coded character sets are recommended. Also further descriptions of coded character sets may be described; it is also possible to document these in the form of a POSIX Charmap registration.

Clause 10: Sorting and searching rules

This is much like clause 1, but can be used for further descriptions, such as how to split a record into sorting fields, and special words which are ignored when comparing or searching. Also sound based matching rules may be described here. What can be accomplished with POSIX should be described in clause 1.

Clause 11: Transformation of characters

Here transliterations and transformations of characters can be described, for example transliteration rules between Latin, Greek and Cyrillic, or fallback notation for some frequent letters. Also this is the place to write about standards in the culture for character conversion.

Clause 12: Character properties

Here additional considerations further than those given in clause 2 can be given, for example how small letters without a direct capital counterpart may be capitalized, or special capitalization rules.

Clause 13: Use of special characters

Here use of special characters, such as quotation marks, abbreviation marks, and punctuation marks can be described. Also interesting here may be what to avoid, for example number signs, pilcrow sign and division signs are not used in documents in several cultures. Spacing rules and the relation between different punctuation signs is also relevant here.

Clause 14: Character rendition

Special considerations about rendition such as what alternatives may be considered adequate, and acceptable glyphs, may be described in this clause.

Clause 15: Character inputting

A keyboard seldom has separate keys for all the characters needed. This clause is intended for description of keyboard inputting rules and other input methods.

Clause 16: Personal names rules

Personal naming differs from culture to culture, for example what is considered the family name, how titles are used, in which order the familiy name and given name come, and whether given names or initial are used. Also the rules for children inheriting their fathers' and mothers' family name, and what happens for married couples may be described here.

Clause 17: Inflection

Languages vary much with respect to inflection, different forms of words depending of the context. here the rules can be described or referenced. Some common translation APIs today take some aspects of this into account, eg. the UNIX gettext() functions deal with singular/plural forms of nouns.

Clause 18: Hyphenation

Hyphenation rules can be described here, and also references to the specifications for a language may be done here.

Clause 19: Spelling

This clause is for specification of spelling rules and spelling lists, or reference to orthographic documentation.

Clause 20: Numbering, ordinals and measuring systems

Here measurement systems can be described (normally this is the ISO SI system). Use of decimal points and thousands separator should be described in clause 3.

Clause 21: Monetary amounts

Here further considerations to clause 4 can be described, such as old currencies.

Clause 22: Date and time

This is for considerations in excess of clause 5, such as non-POSIX date conventions, time zone names and daylight savings rules, and other written expressions like "half seven" - what is then really meant - 06:30 as in Germany or Denmark, or 07:30 as in Britain?

Clause 23: Coding of national entities

Here coding for different entities can be described, such as postal codes, administrative codes for local government, police districts, abbreviations for cities or provinces, and time zone names relating to different parts of the culture.

Also specifications should be given for identification of the whole culture, for example ISO country codes for a nation.

Clause 24: Telephone numbers

The formatting of telephone numbers, nationally and internationally.

Clause 25: Mail addresses

The formatting of postal addresses, where to put the title of the addressee, the street number and the postal code, what are the names of the storeys, and other conventions used.

Clause 26: Identification of persons and organizations

A culture may have numbering schemes for persons and organizations, for example social security numbers, and general tax numbers for companies, together with registries for different organisation forms such as limited companies and associations. This clause may be used to describe such numbering systems.

Clause 27: Electronic mail addresses

Cultural conventions for Internet and X.400 electronic addresses etc. may be described here.

Clause 28: Payment account numbers

Cultural conventions for bank account numbers can be described here.

Clause 29: Keyboard layout

Here the conventions for keyboard layout may be described.

Clause 30: Man-machine dialogue

Considerations for how to localize products may be described here.

Clause 31: Paper formats

Here it can be described what the conventions are for paper size (normally ISO standards) and the use of window envelopes, etc. Also how punched holes are placed in paper may be relevant here.

Clause 32: Typographical conventions

This clause may be used for how layout is done, for example how to layout a business letter, or a fax. Use of special characters, for example quotation marks, should be described in clause 13.

[Karl Ove Hufthammer]:

Eg føretekker skikkelig tidssoneangjeving i staden for kallenamna:

to. 3. april 2003 16:33:35 UTC+2

Dette kan ein få noko fornuftig ut av direkte, i staden for å måtta slå opp på kallenamna, eks. AKDT (Alaska Standard Daylight Saving Time), for å finna ut kva tida er i (UTC-8).

eg likar betre +0200 -- no har vi ei grei tidssone i Noreg, men i andre land er skilnaden i høve til UTC ikkje eit heilt tal timar.

...

...

båe delar er korrekt, men det er meir praktisk med punktum som tusenskiljeteikn, ja.

Har du noen kilder på at begge er korrekt?

Det er *ikkje* korrekt, og det har eg nemnt før <URL: https://init.linpro.no/pipermail/skolelinux.no/linuxiskolen/2002-December/00... >

<URL: http://www.sprakrad.no/tall.htm >:

  Store tall ordner vi i grupper på tre og tre siffer. Det
  skal ikke være punktum noe sted.

  2 500 000 passasjerer
  4 500 800 kroner
  2 500 biler
  0,003 02

viss du tek Språkrådet til inntekt for ditt syn her, må du vel gå inn for punktum i staden for kolon i klokkeslett også?

i handskrift trur eg ikkje det er tvil om at det er mellomrom folk flest brukar som tusenskilje. men det er frykteleg upraktisk i Unix, då.

[Håvard Korsvoll]

Er det mogeleg å formatere datoformatet med tabulator så det går å bruke ulik lengde på månadsnamn.

Nei, det vil ikke fungere.

Evt eit format med lik lengd og eit med ulik lengde.

Det er kanskje mulig.