DATE
field using VirtualShape
does not seem to work correctly.Virtual Shapefile
-
Load Shapefile
On Wed, 23 Jul 2014 00:33:39 -0700 (PDT), mj10777 wrote:
Import of DATE field using VirtualShape does NOT seem to work
correctly.
I Mark,
as you certainly know the DBF format specifications are rather
vague and uncertain.
A datatype DATE is supported, and the corresponding values are
always expected to be internally encoded as YYYYMMDD (plain text);
no further indications are specified.
Accordingly to all this, while importing any DATE value from a
DBF origin spatialite will apply the following actions:
- does the value length exactly corresponds to 8 bytes ?
if NO, then immediately return NULL
- parse the first 4 bytes (Year): is Year between 1900 and 2400 ?
if NO, then immediately return NULL
- parse the next 2 bytes (Month): is Month between 1 and 12 ?
if NO, then immediately return NULL
- parse the last 2 bytes (Day):
is Month in (1,3,5,7,8,10,12) and is Day between 1 and 31 ?
is Month in (4,6,9,11) and is Day between 1 and 30 ?
is Month=2 (leap year) and is Day between 1 and 29 ?
is Month=2 (non leap year) and is Day between 1 and 28 ?
if NO, then immediately return NULL
--
You received this message because you are subscribed to a topic in the Google Groups "SpatiaLite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/spatialite-users/lvd7uPJ3Big/unsubscribe.
To unsubscribe from this group and all its topics, send an email to spatialite-users+unsubscribe@googlegroups.com.
To post to this group, send email to spatialite-users@googlegroups.com.
Visit this group at http://groups.google.com/group/spatialite-users.
For more options, visit https://groups.google.com/d/optout.
Hi Sandro,
I agree with you: telling only the pattern in a date is only part of a full description, even assuming that a DBF was developed with an "en-us" culture in mind.
For that reason the use of those "specs" should be as a general guide, because in real life you have to deal not only with "specs" but with "implementations": shapefiles names (and hence DBF filenames) not following 8.3 naming convention, numeric (N type) values in DBF with comma-separated decimals or in scientific notation (like 1e6), and so on.
And for dates, I agree with the user having the option to choose its interpretation.
--
You received this message because you are subscribed to a topic in the Google Groups "SpatiaLite Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/spatialite-users/lvd7uPJ3Big/unsubscribe.
To unsubscribe from this group and all its topics, send an email to spatialite-use...@googlegroups.com.
To post to this group, send email to spatiali...@googlegroups.com.
2014-07-25 10:09 GMT+02:00 Pac <d.paco...@gmail.com>:
Hi Sandro,
I agree with you: telling only the pattern in a date is only part of a full description, even assuming that a DBF was developed with an "en-us" culture in mind.
Internally (i.e. inside the .dbf files) the date is stored as CCYYMMDD- which is basicly the ISO Date format (which possibly did not exist then) without the '-'-- this can be imported as 'CCYY-MM-DD'All that is needed at the moment is the replacement of :
- Year between 1900 and 2400 ?with
- Year between 0001 and 9999 ?
I guess a more sure solutipn is to avoid to put the / char or allow the user the choice to give him the right mask.
A.
I undersyand you point of view.
To try to detect the most probable value. But, why in the text version import you put the / char ?
I guess a more sure solution is to avoid to put the / char or allow the user the choice to give him the right mask.
A.