[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 09/10/06 17:15:27, Henry Bremridge wrote:
> That doesn't need to be in the file. A single ID is sufficient to > act as a tag with a standard "lookup" table. The fraction, symbols, > currency rates, layouts, formats etc. can all be looked up in fixed > tables that only change comparatively rarely. This is how gnucash > does it. Some apps (like Palm apps) can only support a limited > number of currencies, with limited custom currency ID's for others. > I don't really know enough about how systems work but if for example I am importing a French bank account into my UK system then that willhave the xxx.xxx.xxx,xx format. As long as gnucash or whatever recognises that the .., should be read as ,,. then fine
No, because the xxx.xxx.xxx,xx is NOT to be put into permanent storage of any kind. That's why the Amount field is currency-independent, it is a pure number. €1,234.56 or €1.234,56 makes no odds, in the file it must be stored as 1234.56. The currency ID maps that to the formatting required for that currency so that when the amount is displayed to the user, the app can know whether to put the currency symbol at the start ($£€) or at the end (can't remember which currencies do this but some do) as well as know which separators are used for thousands and which for decimal.
http://pilot-qof.sourceforge.net/manual.html#currencyIt is NEVER wise to store ANY form of localised data in permanent storage. EVER. Identifiers, yes. Localised formats? Absolutely no.
Same goes for timestamps, xsd:date is a good, neutral, format: 2006-10-09T23:40:30Z equates to 9th October, 2006. 11:40.30 pm GMT in an en_GB locale.However, even xsd:date has problems - it has difficulty dealing with dates prior to 1AD because of the use of '-' as the separator.
-044-03-15T08:00:00Z can confuse many POSIX-compliant programs.At least xsd:date can go beyond the 2038 overflow though! I've tested it to 2374499-12-31T23:59:59Z and it can almost certainly go much further but if humans are still around by then, we probably won't be using the current calendar!
Note how the POSIX compliant xsd:date uses YYYY-MM-DD rather than risk the confusing USA/UK problems of MM-DD-YYYY or DD-MM-YYYY. Note also the use of Z which specifies a timezone-independent timestamp (i.e. the timestamp was calculated in UTC, Universal Coordinated Time) which is the same as GMT (and is the same the whole year round, BST is +0100 UTC).
GNU/Linux is internationalised at the source code level and localised at the binary level. i.e. Source code must cope with all possible locales by NOT relying or using any locale-specific code. Binaries are then localised upon installation or at runtime. When a program is translated, the translated strings are read into the binary when the program is started. The same applies to all other forms of localisation (l10n), the application must be neutral (internationalised {i18n}) and the translation/locale support must be l10n compliant. You can test this by changing your LANG variable for a specific program:
$ LANG=fr programProvided a translation exists and you have that locale installed [1], the program will be translated. The program should also pick up locale-specific settings for certain formatting rules - although not every program does this correctly (file a bug).
This is another reason why these expense record files should not be user-editable, at least routinely. (Also another reason why CSV is such a PITA - imagine the chaos when commas are used in currency formats!)
The permanent storage is always POSIX format, hence the correct decimal format for source code and permanent storage is always 1234.56. How that is displayed to the user is a matter for the application to calculate from the installed locale data at runtime.
The basic problem is that although timezones, locales and languages may coincide (GMT/BST infers en_GB and British English), there are plenty of regions where they do not (Cornish is a supported GNU/Linux language, as is Welsh; the Falklands may well use en_GB as their language and locale but IIRC they are -0500 UTC).
[1] On Debian/Ubuntu: $ sudo dpkg-reconfigure locales -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpsBTIKLFMXG.pgp
Description: PGP signature
-- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html