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

Justin_Hickey_via_RT · March 27, 2006, 2:23pm

this bug's URL: http://intevation.de/rt/webrt?serial_num=4214
-------------------------------------------------------------------------

Subject: r.info: new timestamp effort is ambiguous

Hi,

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.

For now rip out the complicated stuff and just use G_format_timestamp()
GRASS has a well developed datetime library, we might as well use it.

[*] I know cause grew up there
[**] e.g. rebuild string from a G_tokenize() list. (don't edit tokens!)

I know the order is documented in the description of 'r.info -p' but you
only see that if you look for it. year/month/day at least forces you to check.

also 'r.info -p' should follow with a '\n'.

thanks,
Hamish

-------------------------------------------- Managed by Request Tracker

Glynn_Clements1 · March 27, 2006, 7:10pm

Request Tracker wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=4214
-------------------------------------------------------------------------

Subject: r.info: new timestamp effort is ambiguous

Hi,

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, 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).

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

--
Glynn Clements <glynn@gclements.plus.com>

H_B · March 28, 2006, 2:56am

> 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

H_B · March 28, 2006, 7:34am

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

this is discussed in the lib/datetime/README document

Also, I pasted the ASCII timestamp specification into the header
comments of lib/gis/timestamp.c yesterday. I am sure it could use
some Doxygenation but don't know that well...

I do not think that the "timestamp" is given to any raster map at map
creation time. It only happens if you specify it. We are not talking
about the "Map creation time" which is saved elsewhere. I understand
this timestamp to be more of a tool for tagging eg LANDSAT images or
orthophotos with their time-of-birth or for work with a time series.

As you can see, timestamp does include the timezone, if given:

* Absolute [timestamps]
*
* The general format for absolute values is:
*
* day month year [bc] hour:minute:seconds timezone
*
* day is 1-31
* month is jan,feb,...,dec
* year is 4 digit year
* [bc] if present, indicates dates is BC
* hour is 0-23 (24 hour clock)
* mintue is 0-59
* second is 0-59.9999 (fractions of second allowed)
* timezone is +hhmm or -hhmm (eg, -0600)
*
* parts can be missing
*
* 1994 [bc]
* Jan 1994 [bc]
* 15 jan 1000 [bc]
* 15 jan 1994 [bc] 10 [+0000]
* 15 jan 1994 [bc] 10:00 [+0100]
* 15 jan 1994 [bc] 10:00:23.34 [-0500]
*

It goes on to describe Relative timestamps.

Hamish

Glynn_Clements1 · March 28, 2006, 8:00pm

Hamish wrote:

> 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.

Right. There are two options for that:

1. Use strftime's "%c" specifier:

%c The preferred date and time representation for the current
locale.

2. Provide a user option (e.g. an environment variable) which
specifies an strftime() format string, falling back to #1 if the
variable (etc) is unset.

--
Glynn Clements <glynn@gclements.plus.com>