Talk:LocalTime

Having added samples for Ripuarian (Colognian) which likely are incomplete and need som additional work, I noticed properties needing additional thought.

general

1. Unless we use "10:03" types of notations, (small) figures are to be spelt out in sentences and non-tabular data.

interval-past

1. For the "# is 1" case, we have two choices to express it. Limburgish and Dutch have them, too. They somewhat vaguely translate to English as, for example, "a month, an hour" versus "one month, one hour", but do not take these as exact translations, since the use cases and connotations differ. in Colognian, the "a month" version may imply gross rounding, while the "one month" version usually does not. But there are other aspects to it regarding focus within a sentence, such as "one" putting it more on the magnitude, whike "a" rather shifts it elsewhere.
2. For some magnitudes, we have two grammatical plurals (to be used with the "# is N" case). Some Ripuarian dialects use only one of those, always. Colognian uses both, and the decision which applies depends on context, rhythmic properties, and possibly speaker preference. That means when you alter or reword a asentence, you may need to swich to the other plural form
3. You could use "yesterday", "in the last week/month/year/century/..." but that is blurry if compared to intervals. On January 1st, almost all of those could coincide with "few minutes ago" as well as "24 hours" ago. Whether or not these words apply, is even time zone dependent. Thus I suggest, to put those calendar based relatives in a class on their own, and not to use them intermingled with true intervals.
4. We have not touched combined magnitudes,
   1. such as "a month and five days age", "a day less five minutes", which becomes awfully complicated since we can and do express those counting upwards and downwards and usually do some rounding. "A month less half a day but an hour and three minutes less seven seconds" would become "A month less almost half a day". If the minor deviations are in the opposite direction, we say: "a month less a good half day".
   2. There are quite complicated rules from decades upwards. So we refer to a century as "100 years", to a century plus a decade" as "110 years", to a millennium and seven centuries as "seventeenhundred years" but never use "tenhundred" for 1000, etc.

These expressions only accept numbers (optionally with decimals).

The places where this can be used are for user input (how long block lasts/when the block ends). Currently it is not flexible enough for more complex expressions like This page was last modified XXX ago. I would think that if we ever get into that far we have a magic word like {{RELATIME:$1|duration|context?}}.

For user input the level of fuzziness or rounding is not so important as for production. If you have ideas how to tackle these issues I'd glad to hear the.

So we have at least the following issues:

1. combined magnitudes
2. approximations
3. tailoring of magnitudes per language (like, avoid decades, prefer years)
4. choosing from multiple possible alternatives by providing some context
5. some expressions like yesterday have additional semantics (very approximate, but day must be different)

   Realistically. if there is some kind of algorithm choosing which magnitude to take, it considers the absolute difference instead of the fact that century might just have changed.

I believe, there is a great overlap between this approach to time expressinos and CLDR time and calendar data. I'll try to find a place where CLDR stuff is documented, but knowing that their publicly available documentations usually are between sparse and hardly organized, while parts are buried in the survey tool and thus semi-private, this may take time. --Purodha Blissenbach 16:15, 9 March 2011 (UTC)

Do you mean this: http://unicode.org/cldr/apps/survey?_=en&x=units

Look even more restricted than my proposal.