Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On 4/23/2012 2:34 PM, Pete wrote: Folks, I'm a bit late to this discussion but what are the new PRAGMAs referred to here? They were discussed hypothetically. As in, wouldn't it be nice if there were pragmas to control date and time formats. -- Igor Tandetnik

[sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

2 > Date: Mon, 2 Apr 2012 20:38:37 +0400 > From: Alexey Pechnikov <pechni...@mobigroup.ru> > To: sqlite-users@sqlite.org > Subject: [sqlite] Suggestion about hard-coded time string format >-MM-DD > Message-ID: >

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On 02.04.2012 18:38 CE(S)T, Alexey Pechnikov wrote: > Why we can't control this? As example, in Russia the date format is > DD.MM. and is needed the patch > http://sqlite.mobigroup.ru/fdiff?v1=288ad2e1e017565c=720cb1015e95af7a > > I think the new pragmas DATEFORMAT and TIMEFORMAT will be

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

2012/4/2 Jay A. Kreibich > It would make more sense to just implement a strptime() SQL function > to compliment the existing strftime() function. That would allow > SQLite to understand and convert any incoming date-time format > without depending on specific build

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/04/12 14:34, Simon Slavin wrote: > I wonder whether it respects languages. A German user living in France has some Swedish names in their list to be sorted. Do you use Swedish sort order, German sort order, German name order or French order?

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On Mon, Apr 2, 2012 at 5:46 PM, Simon Slavin wrote: > Replace part of that routine with something which specifies the locale rather > than fetching it from OS settings.  And store the locale used with the index, > as a COLLATE setting.  Thus leaving it up to whoever writes

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On 2 Apr 2012, at 10:44pm, Igor Tandetnik wrote: > On 4/2/2012 5:34 PM, Simon Slavin wrote: >> Hmm. It's there: >> >> >> >> "The following function compares two Unicode strings of possibly

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On Mon, Apr 2, 2012 at 1:25 PM, Richard Hipp wrote: > On Mon, Apr 2, 2012 at 2:03 PM, Simon Slavin wrote: >> I think ... a higher priority than that would be handling Unicode >> correctly.  And having Unicode support would be useful in writing the code >>

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On Mon, Apr 2, 2012 at 4:24 PM, Simon Slavin wrote: > On 2 Apr 2012, at 9:58pm, Alexey Pechnikov wrote: >> Description: Unicode string library for C >> The 'libunistring' library implements Unicode strings (in the UTF-8, >> UTF-16, and UTF-32

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

At 23:44 02/04/2012, you wrote: I wonder whether it respects languages. These don't, but u8_strcoll et al supposedly do, based on LC_COLLATE locale category. Herein lies the problem: if you build an index using these functions while running under locale A, then try to run queries against

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On 4/2/2012 5:34 PM, Simon Slavin wrote: Hmm. It's there: "The following function compares two Unicode strings of possibly different lengths. — Function: int u8_cmp2 (const uint8_t *s1, size_t n1, const uint8_t

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On 2 Apr 2012, at 10:24pm, Simon Slavin wrote: > On 2 Apr 2012, at 9:58pm, Alexey Pechnikov wrote: > >> Description: Unicode string library for C >> The 'libunistring' library implements Unicode strings (in the UTF-8, >> UTF-16, and UTF-32

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On 2 Apr 2012, at 9:58pm, Alexey Pechnikov wrote: > Description: Unicode string library for C > The 'libunistring' library implements Unicode strings (in the UTF-8, > UTF-16, and UTF-32 encodings), together with functions for > Unicode characters (character names,

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On Mon, Apr 2, 2012 at 3:58 PM, Alexey Pechnikov wrote: > And see too: > > Homepage: http://www.gnu.org/software/libunistring/ Thanks! That looks like a dream come true (even if LGPL). It's much more complete than the OpenSolaris u8_textprep stuff, which would be

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

And see too: # LANG=C aptitude show libunistring0 Package: libunistring0 New: yes State: not installed Version: 0.9.3-3 Priority: optional Section: libs Maintainer: Andreas Rottmann Uncompressed Size: 1221 k Depends: libc6 (>= 2.3) Description: Unicode string library for C The

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On Mon, Apr 2, 2012 at 1:25 PM, Richard Hipp wrote: > On Mon, Apr 2, 2012 at 2:03 PM, Simon Slavin wrote: >> I think ... a higher priority than that would be handling Unicode >> correctly.  And having Unicode support would be useful in writing the code >>

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On 2 Apr 2012, at 7:25pm, Richard Hipp wrote: > On Mon, Apr 2, 2012 at 2:03 PM, Simon Slavin wrote: > >> I think ... a higher priority than that would be handling Unicode >> correctly. And having Unicode support would be useful in writing the code >>

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

Why you need ICU library to parse datetime strings?!! The my previous patch to parse Russian dates has only single row without any external libs. 2012/4/2 Richard Hipp > On Mon, Apr 2, 2012 at 2:03 PM, Simon Slavin wrote: > > > > > I think ... a higher

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On Mon, Apr 2, 2012 at 2:03 PM, Simon Slavin wrote: > > I think ... a higher priority than that would be handling Unicode > correctly. And having Unicode support would be useful in writing the code > which handles dates. > > size of SQLite library: approx 500 KB size of

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On 2 Apr 2012, at 6:18pm, Alexey Pechnikov wrote: > Please see http://www.sqlite.org/lang_datefunc.html and you will be > frustrated because SQLite can format date/time to different string formats > but can't read the produced date/time strings. I am not frustrated.

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

> 2012/4/2 Simon Slavin Please see http://www.sqlite.org/lang_datefunc.html and you will be frustrated because SQLite can format date/time to different string formats but can't read the produced date/time strings. -- Best regards, Alexey Pechnikov. http://pechnikov.tel/

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On Mon, Apr 02, 2012 at 08:38:37PM +0400, Alexey Pechnikov scratched on the wall: > Why we can't control this? As example, in Russia the date format is > DD.MM. and is needed the patch > http://sqlite.mobigroup.ru/fdiff?v1=288ad2e1e017565c=720cb1015e95af7a > > I think the new pragmas

Re: [sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

On 2 Apr 2012, at 5:38pm, Alexey Pechnikov wrote: > Why we can't control this? As example, in Russia the date format is > DD.MM. and is needed the patch > http://sqlite.mobigroup.ru/fdiff?v1=288ad2e1e017565c=720cb1015e95af7a > > I think the new pragmas DATEFORMAT

[sqlite] Suggestion about hard-coded time string format YYYY-MM-DD

Why we can't control this? As example, in Russia the date format is DD.MM. and is needed the patch http://sqlite.mobigroup.ru/fdiff?v1=288ad2e1e017565c=720cb1015e95af7a I think the new pragmas DATEFORMAT and TIMEFORMAT will be helpful for internationalization. These may be used for parsing