[GRASS5] [bug #4214] (grass) r.info: new timestamp effort is ambiguous

[Hamish]

> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4214
> > -------------------------------------------------------------------
> > 
> > Subject: r.info: new timestamp effort is ambiguous
..
> > the new Timestamp: field displayed r.info:
> > 
> >  | Timestamp: 27.3.2006 00:00:00 to none                          |
> >  |----------------------------------------------------------------|
> >  |                                                                |
> >  |   Type of Map:  raster               Number of Categories: 1   |
> >  |   Data Type:    CELL
> > 
> > 
> > This is bad. It should just paste the timestamp as a string the same as
> > r.timestamp does. The current r.info way is ambiguous when day<13 and most
> > people in the US* probably aren't even aware that it can by listed in
> > a way other than month/day/year! A straight dump of the string keeps
> > the months in english, if anything string munging** should happen in r.info
> > to change Jan,Feb,Mar,... to _("January"),_("February"),_("March"),...
> > then the .po files can translate as needed. Maybe as a new fn in 
> > lib/gis/timestamp.c?  G_format_timestamp_l10n() or something.
> 
> If you store a timestamp in a file as a string, it should use a
> defined format,

as it is now,

> rather than using the current locale at the point that
> the timestamp is added.
> 
> If you want localisation, do it when you display the timestamp to the
> user (i.e. in r.info).

G__write_timestamp() would still use G_format_timestamp(); I was 
suggesting G_format_timestamp_l10n() to be used by modules like r.info.


> BTW, the timestamp should probably include the creator's time zone.

this is discussed in the lib/datetime/README document:

The DateTime structure contains a tz param (int, minutes from UTC),

tz:
    The time (hour/minute) in ABSOLUTE types is in local time.
    The specification of a timezone (tz) is an (subtractive)
    offset to convert from local time to UTC.
    To get UTC from localtime: LT - TZ

    tz is expressed in minutes from -720 to 780
    (720 == 12 hours, 780 minutes == 13 hours). 
    [See ANSI X3.51-1975, section 2.2.3]

    For a timezone to be allowed, the 'to' field must be one of
    {MINUTE, SECOND}

[...]

### BROWN
##   so a database only has one timezone?  Or can each map have its own?
### SHAPIRO
##   good question. A location may span more than one time zone. Also timezones
##   are not nice shapes. We probably need a function that returns a timezone
##   for a specified latlon/longitude and/or for a region. How would this
##   function deal with daylight savings time?
##   The timezone(s) might have to be represented as a vector map
##   I suggest we hold off on this and add it later.



Hamish