Details Ticket 4214


Comment | Reply | Take | Open


Serial Number 4214
Subject r.info: new timestamp effort is ambiguous
Area grass6
Queue grass
Requestors hamish_nospam@yahoo.com
Owner none
Status resolved
Last User Contact Sat Apr 8 12:36:45 2006 (2 yr ago)
Current Priority 80
Final Priority 70
Due No date assigned
Last Action Tue Apr 18 11:47:26 2006 (2 yr ago)
Created Mon Mar 27 16:23:47 2006 (2 yr ago)

Transaction History Ticket 4214


Mon, Mar 27 2006 16:23:47    Request created by hbowman  
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
Mon, Mar 27 2006 21:10:55    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17448.14523.473055.42263@cerise.gclements.plus.com>
Date Mon, 27 Mar 2006 20:10:51 +0100
To Request Tracker <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #4214] (grass) r.info: new timestamp effort is ambiguous
In-Reply-To <20060327142347.A31991005D3@lists.intevation.de>
References <20060327142347.A31991005D3@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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>


Tue, Mar 28 2006 04:56:58    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 28 Mar 2006 14:56:31 +1200
From Hamish <hamish_nospam@yahoo.com>
To Glynn Clements <glynn@gclements.plus.com>
Cc grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #4214] (grass) r.info: new timestamp effort is ambiguous
Message-Id <20060328145631.6f948f36.hamish_nospam@yahoo.com>
In-Reply-To <17448.14523.473055.42263@cerise.gclements.plus.com>
References <20060327142347.A31991005D3@lists.intevation.de> <17448.14523.473055.42263@cerise.gclements.plus.com>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
> > 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


Tue, Mar 28 2006 09:34:37    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 28 Mar 2006 19:34:10 +1200
From Hamish <hamish_nospam@yahoo.com>
To glynn@gclements.plus.com
Cc grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #4214] (grass) r.info: new timestamp effort is ambiguous
Message-Id <20060328193410.5c1fbc21.hamish_nospam@yahoo.com>
In-Reply-To <20060328145631.6f948f36.hamish_nospam@yahoo.com>
References <20060327142347.A31991005D3@lists.intevation.de> <17448.14523.473055.42263@cerise.gclements.plus.com> <20060328145631.6f948f36.hamish_nospam@yahoo.com>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
> > 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


Tue, Mar 28 2006 22:00:36    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17449.38363.651309.215615@cerise.gclements.plus.com>
Date Tue, 28 Mar 2006 21:00:27 +0100
To Hamish <hamish_nospam@yahoo.com>
Cc grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #4214] (grass) r.info: new timestamp effort is ambiguous
In-Reply-To <20060328145631.6f948f36.hamish_nospam@yahoo.com>
References <20060327142347.A31991005D3@lists.intevation.de> <17448.14523.473055.42263@cerise.gclements.plus.com> <20060328145631.6f948f36.hamish_nospam@yahoo.com>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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>


Sat, Apr 8 2006 07:19:02    Comments added by hbowman  
Cc: soerengebbert@gmx.de

Sören: any comment on this?


Hamish
Sat, Apr 8 2006 12:36:45    Mail sent by soerengebbert@gmx.de  
Return-Path <soerengebbert@gmx.de>
Delivered-To grass-bugs@lists.intevation.de
X-Authenticated #5818486
From =?utf-8?q?S=C3=B6ren_Gebbert?= <soerengebbert@gmx.de>
To Harmish Bowman via RT <grass-bugs@intevation.de>
Subject Re: [bug #4214] (grass) r.info: new timestamp effort is ambiguous
Date Sat, 8 Apr 2006 12:36:29 +0200
User-Agent KMail/1.8.2
References <20060408051902.A4C161006BC@lists.intevation.de>
In-Reply-To <20060408051902.A4C161006BC@lists.intevation.de>
MIME-Version 1.0
Content-Type text/plain; charset="utf-8"
Content-Transfer-Encoding quoted-printable
Content-Disposition inline
Message-Id <200604081236.30154.soerengebbert@gmx.de>
X-Y-GMX-Trusted 0
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Hi,
i absolutely agree, the current timestamp format of r.info and r3.info is b=
ad.
I fixed this in CVS using G_format_timestamp instead of the self composed o=
utput.
But i have currently no time to take care of a G_format_timestamp_l10n
function, or some environment variable settings to provide=20
localized output, so this have to be wait a bit.

Best
Soeren

On Saturday 08 April 2006 07:19, Harmish Bowman via RT wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3D4214
>=20
> Request number 4214 was commented on by 'hbowman' (Harmish Bowman).=20
> Responding to this message will send mail to the requestor.
> 		=09
> 			Request Tracker
> 			rt@intevation.de
>=20
> --------------------------------------------------------------
> Cc: soerengebbert@gmx.de
>=20
> S=F6ren: any comment on this?
>=20
>=20
>=20
>=20
>=20
> Hamish
>=20
>=20
>=20
>=20
> -------------------------------------------- Managed by Request Tracker
>=20
>=20


Sat, Apr 8 2006 13:53:29    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Sat, 8 Apr 2006 23:53:24 +1200
From Hamish <hamish_nospam@yahoo.com>
To S Gebbert via RT <grass-bugs@intevation.de>
Subject Re: [bug #4214] (grass) r.info: new timestamp effort is ambiguous
Message-Id <20060408235324.77109337.hamish_nospam@yahoo.com>
In-Reply-To <20060408103645.250CC1006D8@lists.intevation.de>
References <20060408103645.250CC1006D8@lists.intevation.de>
X-Mailer Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
X-Face M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
X-Spam-Level
> i absolutely agree, the current timestamp format of r.info and r3.info
> is bad.
> I fixed this in CVS using G_format_timestamp instead of the self
> composed output.

cool, thanks.

> But i have currently no time to take care of a G_format_timestamp_l10n
> function, or some environment variable settings to provide
> localized output, so this have to be wait a bit.

Is it even wanted?


Hamish


Tue, Apr 18 2006 11:47:26    Status changed to resolved by hbowman  
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request