[OSM-dev] OSM Date Formats
jburgess777 at googlemail.com
Sun Sep 30 12:50:36 BST 2007
On Sun, 2007-09-30 at 10:26 +0000, Robert Hart wrote:
> On 30/09/2007, Brett Henderson <brett at bretth.com> wrote:
> > Robert Hart wrote:
> > > On 29/09/2007, Brett Henderson <brett at bretth.com> wrote:
> > >
> > >> I'd like to standardise on a UTC date with Z suffix similar to the
> > >> osmosis example. I am willing to remove the millisecond information to
> > >> make it even shorter if necessary (I'll have to write my own formatter
> > >> but not a big job). As a nice side effect this would noticeably reduce
> > >> the size of the planet.
> > >>
> > >
> > > To be honest I'm really surprised that a timestamp is passing from the
> > > client through the server into the database without being parsed at
> > > all. Surely a) a proper timestamp format can and should be used in the
> > > db. and b) we shouldn't necessarily be trusting the time as determined
> > > by the client anyway.
> > >
> > > Rob
> > >
> > Um, I think we're talking about different things. I'm talking about
> > when planet.rb reads data from the database and puts it in the planet
> > file. This has nothing to do with writing changes into the database
> > where (as you say) the database or API code should assign its own
> > timestamp without trusting the client.
> > The database itself doesn't require a timestamp "format" because dates
> > aren't stored as strings, they're stored in a MySQL timestamp field.
> If timestamps aren't stored as strings, why do you get different
> formats depending on which client created the object?
You don't. It makes no difference which client wrote the data. The
different clients mentioned in the OP were examples of applications
which can save some form of <osm> format file.
Each one of these applications originally gets information from the DB,
API or saved file and parses the date to some internal format. When it
saves the output into an <osm> file it outputs the data/time in whatever
is natural for the particular language/library that the application uses
to generate XML. Unfortunately they are often different.
If you are writing another application which takes <osm> files from any
source then it is painful to have to support reading all these different
date/time formats. If we were consistent on the format then the tools
can be made faster, more efficient and better able to detect errors.
More information about the dev