This is not an ESRI issue, because the specification of the DBF structure antedates ESRI's use (in shapefiles) by more than a decade.
I will discuss the standard dBase III specification, because that is essentially what shapefiles use. (The link in the question is to a much more recent extension of the format, "dBase 7," which is by no means universal or standard and is unlikely to be supported by much software.)
You are correct that internally the data are stored as ASCII character strings. DBF III supports just four types: character, date, logical, and numeric. (I am omitting discussion of a "memo" field because it is not supported in shapefiles and requires an auxiliary binary file.) A "numeric" field type indicates that the ASCII string should be interpreted essentially as if it were typed in (in base 10). This differs from float and double formats in which values are stored in a binary format consisting of a base two "mantissa," a base two exponent, and a sign bit.
Another aspect of the DBF III format is that all contents of the data records are interpreted as ASCII character strings. The presence of certain characters (such as an end-of-file marker) can cause some software to terminate reading of the file. Therefore--although it may be a tempting idea--it would be unwise to try to circumvent the DBF standard by storing binary formatted data within the DBF records, because sooner or later such "control characters" like EOF will occur.
To make the most of limited file space, it is worth considering what the inherent precision of the data will be. For instance, a number like "12.3456789123456789," if it represents (say) an elevation in meters, likely contains a lot of meaningless "noise" at the end and could safely be rounded to 12.346, 12.35, 12.3, or even 12, depending on the precision and intended application. When creating the DBF file you need to provide for enough characters to store the longest value anticipated, to sufficient precision to meet all foreseeable needs. For instance--returning to the elevation example--if you need to accommodate most ground elevations to two decimal places in meters, the ASCII patterns will range from -xxx.xx (which can represent elevations down to -999.99 meters) through xxxx.xx (i.e., up to 9,999.99 meters). Consequently you would need at least seven characters (even the decimal point counts as one!). You would declare this field to be numeric of width 7 with 2 decimal places. By applying such thinking, you might be able to squeeze some bytes out of the file and stay under the 2 GB size limit imposed by Arc* software. (The DBF III standard itself uses unsigned offsets and can thereby accommodate 4 GB, as I recall.)
If you don't have a .dbf file, you probably have an empty attribute table.
To get the X and Y of a point layer, you have to add them to the attribute table using the field calculator. $X and $Y from the Geometry section will add the coordinate values. Be sure to change the field type to real, and set the precision greater than zero if using degrees.
For a line or polygon layer, you can export the coordinates of the line vertices with the mmqgis plugin to a CSV file.
Best Answer
Unlike a number of data formats of its time, dBase-III was "Y2K" compliant (it used the extra bytes necessary to store the actual year in four digits). Unfortunately for modern uses, this came at the cost of not storing time values at all.
The dBase field buffer for
D
type values utilizes eight characters, in the formatYYYYMMDD
(delimiters would have only increased the storage requirement 25%).It appears that the Python interface you are using does not validate or otherwise enforce proper date value formatting, so you are required to provide the exact date format used in the transfer buffer. In
strftime
syntax, that would be to use the format string'%Y%m%d'
.