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