[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Date parsing in Postgres/GNUmed

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Date parsing in Postgres/GNUmed
Date: Tue, 2 Aug 2011 16:03:19 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Jul 30, 2011 at 01:06:50AM -0700, Jim Busser wrote:

> > The format MM/DD/YY is unique to the United States. Most of Europe uses 
> > DD/MM/YY. Japan uses YY/MM/DD. The separators may be slashes, dashes or 
> > periods. Some locales print leading zeroes, others suppress them. If a 
> > native Japanese speaker is reading a US English web page from a web site in 
> > Germany that contains the date 03/04/02 how do they interpret it?
> after which I did the following:
>       #exited GNUmed
>       # stopped postgres server, using binaries from Enterprise DB 
> /Applications/PostgreSQL\ 8.4
>       #set locale to Japanese
>       export LC_ALL=ja_JP.UTF-8
>       #observe the effect
>       locale LC_TIME
>       #restart postgres server
>       #load GNUmed
>       #try inputting valid Japanese date in official format yy mm dd (using 
> official / )
>               84/8/12 --> rejected since the slash treats 84 as invalid, 
> assuming mm dd yy

This is what GNUmed does when parsing a string into a fuzzy
timestamp or a Python datetime timestamp:

- generate a few suggestions when there is in the string:

        - only a single "."
        - only numbers
        - only a single "/"
        - only a single character
        - only an explicit offset definition (+6w = +6 weeks)

- it then adds suggestions generated (if mx is available)
        - using mx.DateTime.Parser.DateFromString()
        - applying the pre-defined format types:
                'euro', 'iso', 'us', 'altus', 'altiso', 'lit', 'altlit', 

- it then adds more suggestions
        - using Python's time.strptime()
        - with some patterns passed in and
        - a few hard-coded patterns:

All these methods are additive, rather than exclusive.

Further details are available in pycommon/

GNUmed never anywhere explicitely tries (or claimed to try
to my knowledge) to conform to the locale over and above
what the underlying modules (mx.DateTime and Python
datetime) do.

The design principles are:

1) It is not possible to know what the user actually wanted
   without forcing the user into a pre-defined scheme.

2) Hence, provide as many candidate/partial timestamps as
   can be generated from the input of the user.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]