Behavior of t.register when r.timestamp was used

[wenzeslaus]

I'm trying to figure out what is the right behavior and usage of t.register in case when the raster map already has a "simple GRASS" time stamp (managed e.g. by r.timestamp).

For example, r.sim.water with -t produces time series which has time stamps from G_write_raster_timestamp(). The time stamps are relative.

Later, when you create a temporal dataset using t.create and set absolute time and use t.register to register the map or maps providing the start time and increment, you get an error saying that the time and date provided as start cannot be converted to integer.

Here is the code to reproduce it:

Error: Failed to load processor bash

No macro or processor named 'bash' found

And this is the error:

ERROR: invalid literal for int() with base 10: '2015-01-01 00:01:00'

It comes from:

if ttype == "absolute":
    ...
else:
    start_time = int(start)  # here

The time stamp is read from the spatial database in register.py​:

if not is_in_db:
    map.read_timestamp_from_grass()

The condition doesn't depend on the input parameters to t.register and the behavior seems to be unexpected from the user point of view (plus of course there should be no low-level error like this one).

[huhabla]

This is indeed a strange error. I will fix the register method to use only the time stamp from the spatial database, when no time stamp was provided on the command line or in the input file.

One reason why this error happened is that r.sim.water creates a relative time stamp and you specified an absolute time stamp on the command line. Hence, the wrong time stamp conversion.

Interesting error case that i did not test.

[huhabla]

This issue should be fixed in r69586.

[wenzeslaus]

Thanks. Works for me now. And the date in the spatial database is overwritten.

> r.timestamp depth.02
1 Jan 2015 00:01:00

This should be probably backported.

[neteler]

Replying to huhabla:

This issue should be fixed in r69586.

Backported in r69802. Can we close this?

[wenzeslaus]

Replying to neteler:

Backported in r69802. Can we close this?

Yes.