Opened 10 years ago

Closed 6 years ago

Last modified 6 years ago

#3919 closed enhancement (fixed)

when modifying dbf, set current date in header

Reported by: dfuhry Owned by: warmerdam
Priority: normal Milestone: 2.0.0
Component: OGR_SF Version: svn-trunk
Severity: normal Keywords: shape dbf date
Cc: michalis


Currently when OGR modifies a DBF file, the "date of last update" field is set to the hardcoded value 07/26/95.

The attached patch to ogr/ogrsf_frmts/shape/dbfopen.c causes it to be set to the current date. Tested in Linux.

dbf file format:

Attachments (1)

dbfopen_set_correct_date.v1.patch (1.2 KB) - added by dfuhry 10 years ago.

Download all attachments as: .zip

Change History (5)

Changed 10 years ago by dfuhry

comment:1 Changed 10 years ago by Even Rouault

Similar ticket opened as #3989

comment:2 Changed 6 years ago by Jukka Rahkonen

Cc: michalis added

This feels theoretically as a right thing to do but I am not sure about it. These are my arguments:

  • The format of the date of last update is YYMMDD. All versions saved on the same day have the same value and which one is newest must be solved in some other way.
  • The last update field is unreliable. GDAL puts it always into YYMMDD 95-07-26 but by in investigation I made to my shapefile archive it does not seem to be the only software that is using some fixed value. Unfortunately I can't name the other programs. However, ArcGIS, MapInfo?, and GeoTools? based programs seem to use the current day as suggested in this ticket.
  • The meaning of "last updated" is unclear by definition in context of shapefiles. It makes more sense when dBase file is used as database data file. Obviously it was made to mean something else than the creation date of the file, the date when the data was updated. But if you edit the geometries but not attributes, should the "last updated" header remain the same when the edits are saved? Or when you download a zipped shapefile from GeoServer? WFS and it creates a new shapefile for every request with a new .dbf and last updated value set to the creation date of the file. Is that a right thing to do if data on the server is not updated? Well, I admit that saying "data was valid at YYMMDD when the shapefile was created" gives more information than using a dummy date which means effectively "use other means for solving when the shapefile was created".
  • I don't know how many GIS programs really read the dbf headers and interpret them for the users.

I am not against making the change because I can't imagine that it could break anything. On the other hand, I think that the last edited header in .dbf file is a piece of metadata with very little of practical meaning. Only use case I can imagine is for resolving when the shapefile was created if the file creation date is lost.

I can't read C code and can't say for sure if the patch is right or not. The YY bit should be added to base year 1900, thus hex values 00-FF will cover year range 1900-2155. I checked what OpenOffice? Calc does and it makes it wrong by saving the YY for the year 2015 as "0F" (decimal 15) even it should save it as "73" (decimal 115). This means that no software that reads dbf files should be made to validate the last modified bytes in the header.

I am closing the duplicate ticket #3989 and leave this ticket open at least for a few weeks. If nobody reacts and requests to keep this ticket open it may happen that I will close it as "wontfix".

comment:3 Changed 6 years ago by Even Rouault

Keywords: shape dbf date added
Milestone: 2.0
Resolution: fixed
Status: newclosed
Type: defectenhancement

trunk r28337 "Shapefile: fill 'date of last update' header with current time instead of dummy date, and add a DBF_DATE_LAST_UPDATE layer creation option to override this with a fixed date (#3919)"

comment:4 Changed 6 years ago by Even Rouault


Milestone renamed

Note: See TracTickets for help on using tickets.