Proposal: loi lerfu tcita detri; the final word on the problem of dates and times?

[Spheniscine (la zipcpi)]

http://mw.lojban.org/papri/Proposal:_loi_lerfu_tcita_detri;_the_final_word_on_the_problem_of_dates_and_times%3F

[la durka]

mi nelci mutce .i'e ui .i mi na birti lo du'u lo romoi no'u lo detri ditcu ciste cu sarcu .iki'ubo zo bi'o jai banzu pe'i iepei

ni'o mi ca nau co'a .aidji lo ka sampla la za'e detrivo .i'au .u'i

- mu'o mi'e durkavore

El domingo, 17 de mayo de 2015, 13:56:43 (UTC-4), Spheniscine (la zipcpi) escribió:

http://mw.lojban.org/papri/Proposal:_loi_lerfu_tcita_detri;_the_final_word_on_the_problem_of_dates_and_times%3F

[Spheniscine (la zipcpi)]

bi'o isn't sufficient for arbitrary units of time not anchored to a specific date, e.g. "three years and four days", but I already gone through that in our IRC convo :p

On Monday, May 18, 2015 at 1:56:43 AM UTC+8, Spheniscine (la zipcpi) wrote:

http://mw.lojban.org/papri/Proposal:_loi_lerfu_tcita_detri;_the_final_word_on_the_problem_of_dates_and_times%3F

[Spheniscine (la zipcpi)]

Actually the discussion about periods has led to more than how to just represent units of time; but also concepts like miles per hour, meters per second-squared, etc.

I have been told about the existence of two experimental cmavo, {pi'ai} (multiplication prefix, in selma'o KE) and {te'ai} (exponentiation subscript, in selma'o XI) that can be used for specialized tanru. So 30 miles per hour = lo pi'ai minli cacra te'ai ni'upa be li cino , and 9.8 meters per second-squared = lo pi'ai mitre snidu te'ai ni'ure be li sopibi . Unfortunately these constructions can be a little long.

One crazy idea I thought of was... what if we had a PA cmavo for every unit of measurement? After all, they are treated much like algebraic constants in calculations. So assuming [mai'i] = minli and [cai'ai] = cacra, you can have have 30 miles per hour = li cino pi'i mai'i fe'i cai'ai , or assuming [nai'a] for year and [jei'i] for day, three years and four days = li ci pi'i nai'a su'i vo pi'i jei'i (fau'u rodo I forgot if Lojban mathematical precedence works this way, or if I need mathematical brackets which I forgot how to use). Do we nearly have the cmavo space for this though, and would the semantic hooks be enough? Also they might still be a tad long - do we really need all these pi'i-s?

You see, the main barrier to Lojbanizing mathematical and scientific conventions is that mathematical variables are so often overloaded, as there are only so many letters to go around. Even the familiar symbol of π is given many other meanings besides the ratio of the circumference to the diameter. 

But Lojban, on the other hand, has a theoretically-infinite number of words to assign to these variables to. Unfortunately though, syllabicity is still a practical issue. The constraints of cmavo space is another; consonants provide more bits than vowels and diphthongs do, but a cmavo is only allowed one consonant at the beginning.

[Spheniscine (la zipcpi)]

Another idea: define {to'e broda}, where broda is a measurement unit, to mean {broda te'ai ni'upa}; i.e. the reciprocal of the unit.

Thus {to'e snidu} = s^-1 or Hertz, {to'e mitre} = m^-1 or diopter. Philosophical basis is that now these units are no longer measuring length but shortness, in time and in space respectively.

So now miles per hour is {lo pi'ai minli to'e cacra}. {pi'ai} may be droppable from all but the most technical contexts: just assume via convention that when we put two measurement units in a tanru, we intend to multiply them. Then we can possibly build the lujvo {minlytolcacra} (though the La Bangu project does want to avoid proliferating lujvo). This possibly fixes the problem that existing measurement-combination lujvo such as {cacryminli} have no standard as to how they should be constructed.

[Alex Burka]

Not a terrible suggestion! What about higher powers, though? Torque is measured in kg*m^2/s^2 == ki'ogratretretolnidytolsnidu? Or ki'ogratretretolkemnidysnidu?

--
You received this message because you are subscribed to a topic in the Google Groups "lojban" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lojban/s5aV14VFN5s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lojban+un...@googlegroups.com.
To post to this group, send email to loj...@googlegroups.com.
Visit this group at http://groups.google.com/group/lojban.
For more options, visit https://groups.google.com/d/optout.

[Alex Burka]

sa'ai

ki'orgratretretolnidytolsnidu

ki'orgratretretolkemnidysnidu

le'ai

[Spheniscine (la zipcpi)]

I kinda assume that certain units like the newton, watt, etc. will have zi'evla coined for them to shorten the more complicated dimensions.

[Alex Burka]

Yes, I agree (for newtons we currently have *{niutni} [which needs to be fixed morphologically, maybe to {klanrniiutni} or {cniiutni}] and {ki'orgratretrefrinynidysnidu}, and for joules we have the more reasonable {djaule}). But if we're thinking about a system then it's good to know how to write things out.

On May 19, 2015 at 10:52:34 AM, Spheniscine (la zipcpi) (sphen...@gmail.com) wrote:

I kinda assume that certain units like the newton, watt, etc. will have zi'evla coined for them to shorten the more complicated dimensions.

[Pierre Abbat]

On Tuesday, May 19, 2015 01:34:32 Spheniscine wrote:
> Another idea: define {to'e broda}, where broda is a measurement unit, to
> mean {broda te'ai ni'upa}; i.e. the reciprocal of the unit.

Why "to'e" instead of making a lujvo with "frinu"?

Pierre
--
La sal en el mar es más que en la sangre.
Le sel dans la mer est plus que dans le sang.

[Pierre Abbat]

On Tuesday, May 19, 2015 10:57:19 Alex Burka wrote:
> Yes, I agree (for newtons we currently have *{niutni} [which needs to be
> fixed morphologically, maybe to {klanrniiutni} or {cniiutni}] and
> {ki'orgratretrefrinynidysnidu}, and for joules we have the more reasonable
> {djaule}). But if we're thinking about a system then it's good to know how
> to write things out.

{ni'utni} is valid. It has the same pattern as {ma'agni} (which is a tree, not
a unit).

Pierre
--
The gostak pelled at the fostin lutt for darfs for her martle plave.
The darfs had smibbed, the lutt was thale, and the pilter had nothing snave.

[Spheniscine (la zipcpi)]

Yeah I suppose that could work for regularized lujvo. {minlyfrinycacra} is kinda long though and doesn't work quite so well as tanru, with or without {pi'ai}

[la gleki]

On Sunday, May 17, 2015 at 8:56:43 PM UTC+3, Spheniscine (la zipcpi) wrote:

http://mw.lojban.org/papri/Proposal:_loi_lerfu_tcita_detri;_the_final_word_on_the_problem_of_dates_and_times%3F

I'd say that this is by far the best usable method of talking about both dates and periods.

The problem with the original {de'i} is that one can never know what {de'i li 7} means. Whether it's year 7 AD, December, day 7 of some month, week No. 7 of some year or even Sunday or Saturday.

L4B solves this problem by stating that one number after {de'i} denotes day, two number denote DD/MM etc. with {pi'e} being a separator.

This letteral solution 

1. allows for free "word" order, 

2. solves period/datetimestamp problem within one brivla/tag although {ti'u} can be a convenient addition to {de'i}

3. doesn't fill the dictionary with numerous words

Disadvantages:

a. Like it's {pi'e} equivalent it's not a predicate language. An expansion of these rules into predicates is needed for linguistic purposes no matter how verbose the expansion will be (i.e. its value for everyday usage is irrelevant). {citsi} also has to be explained in this expansion since it is one of the few "splicing time interval" brivla. relations like {ca}/date, {ze'a}/period are to be explained.

b. Those are new rules injected into the language. Multiplying entities is usually not good. Although they actually make {pi'e} solution not needed so in total the required part of the language becomes less heavy.

c. timezone can't be easily specified inside {de'i} using names of countries.

We should also note that in most major languages both "month" and "minute" start from the same letter which ultimately led to {masti} and {mentu} to start with the same letter. This solution doesn't actually involve current brivla for time periods so using {ly} for "calendar month" might not even lead to the need in making a brivla for "month" starting with "l-". 

[Jorge Llambías]

On Sun, May 31, 2015 at 9:22 AM, la gleki <gleki.is...@gmail.com> wrote:

Disadvantages:

a. Like it's {pi'e} equivalent it's not a predicate language. An expansion of these rules into predicates is needed for linguistic purposes no matter how verbose the expansion will be (i.e. its value for everyday usage is irrelevant). {citsi} also has to be explained in this expansion since it is one of the few "splicing time interval" brivla. relations like {ca}/date, {ze'a}/period are to be explained.

b. Those are new rules injected into the language. Multiplying entities is usually not good. Although they actually make {pi'e} solution not needed so in total the required part of the language becomes less heavy.

c. timezone can't be easily specified inside {de'i} using names of countries.

d. It will break down if (and hopefully when) digit strings become disentangled from letter strings.

mu'o mi'e xorxes

[Spheniscine (la zipcpi)]

I've not heard of that proposal. Wouldn't that just break all uses of {xy pa} when talking about the definitions of words? 

Besides, {me'o} still works, paralleling the use of strings for entry of ISO dates in programming languages. I just prefer {li} because

• It's shorter
• Dates and periods technically *are* numbers in a certain sense; arithmetic can be performed on them, despite the fact that in some ways they don't act like real-numbers, due to the varying length of months and years.

[Alex Burka]

No problem, if you manage to convince us of that we can just define a new {li}-alike that takes an arbitrary number of digit strings & lerfu strings and glues them together :)

--

[Alex Burka]

Not sure anyone agrees in how to mark places in jbojbo definitions anyway. Though if you watch Selckiku's old videos, he says {xyxipa} not {xypa}. That said I still like this date notation :)

--

[Jorge Llambías]

On Sun, May 31, 2015 at 2:09 PM, Spheniscine (la zipcpi) <sphen...@gmail.com> wrote:

I've not heard of that proposal. Wouldn't that just break all uses of {xy pa} when talking about the definitions of words? 

Those are "xy xi pa".

The contexts where we don't want digits and lerfu to mix (e.g. ".abu za'u re'u cusku", "by re mei", "lo re bolci zo'u pa by xunre .i je pa by blanu", "xy xi pa dunda xy xi re xy xi ci" etc. are much much more common than the need for mixed strings, and having to use "boi" for those is a pain.

Besides, {me'o} still works, paralleling the use of strings for entry of ISO dates in programming languages. I just prefer {li} because

• It's shorter
• Dates and periods technically *are* numbers in a certain sense; arithmetic can be performed on them, despite the fact that in some ways they don't act like real-numbers, due to the varying length of months and years.

"me'o" and "li" are in the same selma'o, so the issue is the same for both.

[Spheniscine (la zipcpi)]

"me'o" and "li" are in the same selma'o, so the issue is the same for both.

Under your proposal they wouldn't (or at least shouldn't) be, because me'o is used for arbitrary character strings. How else will you be able to spell out a password like "utT53fpB"?

[Jorge Llambías]

On Sun, May 31, 2015 at 3:01 PM, Spheniscine (la zipcpi) <sphen...@gmail.com> wrote:

"me'o" and "li" are in the same selma'o, so the issue is the same for both.

Under your proposal they wouldn't (or at least shouldn't) be, because me'o is used for arbitrary character strings. How else will you be able to spell out a password like "utT53fpB"?

You can use the lerfu "mu bu" and "ci bu". 

[Spheniscine (la zipcpi)]

You can use the lerfu "mu bu" and "ci bu". 

That would make digit-heavy character-strings extremely clunky. Besides, if we're going to have to define a new selma'o anyway to retain compatibility, it might as well be MEhO.

[Jorge Llambías]

On Sun, May 31, 2015 at 3:14 PM, Spheniscine (la zipcpi) <sphen...@gmail.com> wrote:

You can use the lerfu "mu bu" and "ci bu". 

That would make digit-heavy character-strings extremely clunky. Besides, if we're going to have to define a new selma'o anyway to retain compatibility, it might as well be MEhO.

Or just use "lo'u" if what we want is just a string of characters without any internal grammar. But li/me'o take a mathematical expression, not just any character-string, one returns an expression and the other returns its value. It would be strange for them to have different grammars, because then you couldn't distinguish the value from expression by just choosing "li" or "me'o".

[Gleki Arxokuna]

Could someone please correct this proposal to match this proposed grammar but while being still gendra currently?

mu'o mi'e xorxes

--

You received this message because you are subscribed to the Google Groups "lojban" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lojban+un...@googlegroups.com.

[Alex Burka]

I don't see a reason to mix proposals like that. Unmerging lerfu and digit strings would make this date representation more cumbersome, but that counts against Xorxes' suggestion, not zipcpi's.

You received this message because you are subscribed to a topic in the Google Groups "lojban" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lojban/s5aV14VFN5s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to lojban+un...@googlegroups.com.

[Spheniscine (la zipcpi)]

Or just use "lo'u" if what we want is just a string of characters without any internal grammar. But li/me'o take a mathematical expression, not just any character-string, one returns an expression and the other returns its value. It would be strange for them to have different grammars, because then you couldn't distinguish the value from expression by just choosing "li" or "me'o".

{ienai}. 

{me'o dy ubu ry ky abu vo re} -> "durka42"

{lo'u dy ubu ry ky abu vo re le'u} -> "dy ubu ry ky abu vo re"

[Spheniscine (la zipcpi)]

I dunno, {doi .xorxes.}, I can get behind your complaints about {boi} (after all I made {la bauspo fazykamni}), but you're not exactly selling yourself well here. We've gone from {li} to {me'o} to {lo'u ... le'u}. What's next, {la'e lo'u ... le'u}? {paunai xo'oru'e}

[Gleki Arxokuna]

e. To say "Monday" one will have to resort to {se detri be li jydy pa}, not a very short expression, same for months. So to imitate major languages the 7+12 extra words (pavdei, pavmasti etc. or equivalents) might still be needed.

mu'o mi'e xorxes

--

[Spheniscine (la zipcpi)]

e. To say "Monday" one will have to resort to {se detri be li jydy pa}, not a very short expression, same for months. So to imitate major languages the 7+12 extra words (pavdei, pavmasti etc. or equivalents) might still be needed.

Yeah I can see that. {ca de'i li jydy xo} is still probably the best way to ask "What day of the week is it" though; I mean, {lo cabdei cu mo} is rather ambiguous :p

[Spheniscine (la zipcpi)]

There's also {ca jefydei li xo}, which I entered, but there would need to be equivalents for each other field.

[Gleki Arxokuna]

2015-06-01 10:04 GMT+03:00 Spheniscine (la zipcpi) <sphen...@gmail.com>:

e. To say "Monday" one will have to resort to {se detri be li jydy pa}, not a very short expression, same for months. So to imitate major languages the 7+12 extra words (pavdei, pavmasti etc. or equivalents) might still be needed.

Yeah I can see that. {ca de'i li jydy xo} is still probably the best way to ask "What day of the week is it" though; I mean, {lo cabdei cu mo} is rather ambiguous :p

e.g. http://en.wikipedia.org/wiki/Sunday_(2008_film)

(as a part of name)

[guskant]

Le lundi 1 juin 2015 06:54:48 UTC, la gleki a écrit :

2015-05-31 15:32 GMT+03:00 Jorge Llambías <jjlla...@gmail.com>:

On Sun, May 31, 2015 at 9:22 AM, la gleki <gleki.is...@gmail.com> wrote:

Disadvantages:

a. Like it's {pi'e} equivalent it's not a predicate language. An expansion of these rules into predicates is needed for linguistic purposes no matter how verbose the expansion will be (i.e. its value for everyday usage is irrelevant). {citsi} also has to be explained in this expansion since it is one of the few "splicing time interval" brivla. relations like {ca}/date, {ze'a}/period are to be explained.

b. Those are new rules injected into the language. Multiplying entities is usually not good. Although they actually make {pi'e} solution not needed so in total the required part of the language becomes less heavy.

c. timezone can't be easily specified inside {de'i} using names of countries.

d. It will break down if (and hopefully when) digit strings become disentangled from letter strings.

e. To say "Monday" one will have to resort to {se detri be li jydy pa}, not a very short expression, same for months. So to imitate major languages the 7+12 extra words (pavdei, pavmasti etc. or equivalents) might still be needed.

 The current topic is related to usage of BAI, and not related to brivla for names of [months/days of a week]. The item e. therefore should not to be counted. On the otherhand, the item d. is much important for me to disagree the proposal.

Le lundi 1 juin 2015 07:04:56 UTC, Spheniscine (la zipcpi) a écrit :

e. To say "Monday" one will have to resort to {se detri be li jydy pa}, not a very short expression, same for months. So to imitate major languages the 7+12 extra words (pavdei, pavmasti etc. or equivalents) might still be needed.

Yeah I can see that. {ca de'i li jydy xo} is still probably the best way to ask "What day of the week is it" though; I mean, {lo cabdei cu mo} is rather ambiguous :p

Currently, {de'i'u xo} is the shortest and unambiguous. For brivla form, {ma jefydeidetri lo nu broda} is unambiguous.

For a point on time axis in merging {de'i} and {ti'u}, {te'i} can be applied: 

mi ciska te'i li 2015-06-01 07:27 noi sinxa lo mentu ku'o tete'i U'yTyCy

.i

mi ciska te'i li 2457174.810416667 tete'i la juli'us

mu'o

[guskant]

Sorry again, {de'i'u ma} is the shortest, not {xo}. We may say {de'i'u li xo} instead, of course.

 mu'o

[Spheniscine (la zipcpi)]

Yes I have seen those trisyllabic date BAI-tags, but while they are shorter for the particular scenario I brought up, they are horribly inconvenient for use for entire dates.

{de'i'e li renopamu de'i'i li xa de'i'o li pa de'i'u li pa} vs.

{de'i li ny renopamu ly xa dy pa jydy pa}

[guskant]

de'i'V series is intended for selecting an item of date notation. For full notation of a date+time, use {te'i}. 

[Spheniscine (la zipcpi)]

ue ua A tri-letteral experimental cmavo that doesn't begin with {x}?

Anyway looking it up, it still has one of the problems of {pi'e}: it's easy to get lost as to which number you're on, especially since the date and the time are both run together.

[guskant]

Le lundi 1 juin 2015 07:50:59 UTC, Spheniscine (la zipcpi) a écrit :

ue ua A tri-letteral experimental cmavo that doesn't begin with {x}?

xVVV... form cmavo are room for experimental cmavo, but I don't think experimental cmavo "should be" first proposed in xVVV... form. 

 

Anyway looking it up, it still has one of the problems of {pi'e}: it's easy to get lost as to which number you're on, especially since the date and the time are both run together.

I know that the form of the sumti in de'i/ti'u/te'i is indeed your proposal. I mentioned de'i'V series only for letting you know the shortest form is {de'i'u ma}, not {ca de'i li jydy xo}. I don't intend to discuss the current topic for now. Please continue without me.

mu'o

[Gleki Arxokuna]

2015-06-01 10:27 GMT+03:00 guskant <gusni...@gmail.com>:

Le lundi 1 juin 2015 06:54:48 UTC, la gleki a écrit :

2015-05-31 15:32 GMT+03:00 Jorge Llambías <jjlla...@gmail.com>:

On Sun, May 31, 2015 at 9:22 AM, la gleki <gleki.is...@gmail.com> wrote:

Disadvantages:

a. Like it's {pi'e} equivalent it's not a predicate language. An expansion of these rules into predicates is needed for linguistic purposes no matter how verbose the expansion will be (i.e. its value for everyday usage is irrelevant). {citsi} also has to be explained in this expansion since it is one of the few "splicing time interval" brivla. relations like {ca}/date, {ze'a}/period are to be explained.

b. Those are new rules injected into the language. Multiplying entities is usually not good. Although they actually make {pi'e} solution not needed so in total the required part of the language becomes less heavy.

c. timezone can't be easily specified inside {de'i} using names of countries.

d. It will break down if (and hopefully when) digit strings become disentangled from letter strings.

e. To say "Monday" one will have to resort to {se detri be li jydy pa}, not a very short expression, same for months. So to imitate major languages the 7+12 extra words (pavdei, pavmasti etc. or equivalents) might still be needed.

 The current topic is related to usage of BAI, and not related to brivla for names of [months/days of a week]. The item e. therefore should not to be counted. On the otherhand, the item d. is much important for me to disagree the proposal.

Le lundi 1 juin 2015 07:04:56 UTC, Spheniscine (la zipcpi) a écrit :

e. To say "Monday" one will have to resort to {se detri be li jydy pa}, not a very short expression, same for months. So to imitate major languages the 7+12 extra words (pavdei, pavmasti etc. or equivalents) might still be needed.

Yeah I can see that. {ca de'i li jydy xo} is still probably the best way to ask "What day of the week is it" though; I mean, {lo cabdei cu mo} is rather ambiguous :p

Currently, {de'i'u xo} is the shortest and unambiguous.

Well, conciseness is to be counted by assessing multiple test sentences in total. E.g. what is the shortest "In Monday, Jan. 1" in the two (three counting xorxe's proposal) systems etc.

For brivla form, {ma jefydeidetri lo nu broda} is unambiguous.

For a point on time axis in merging {de'i} and {ti'u}, {te'i} can be applied: 

mi ciska te'i li 2015-06-01 07:27 noi sinxa lo mentu ku'o tete'i U'yTyCy

.i

mi ciska te'i li 2457174.810416667 tete'i la juli'us

mu'o

--

[Spheniscine (la zipcpi)]

xVVV... form cmavo are room for experimental cmavo, but I don't think experimental cmavo "should be" first proposed in xVVV... form. 

It isn't about should. It is that I was surprised that there was still cmavo space left there (I'm sure someone would post a list soon :p) 

[guskant]

Le lundi 1 juin 2015 08:03:51 UTC, guskant a écrit :

I know that the form of the sumti in de'i/ti'u/te'i is indeed your proposal. I mentioned de'i'V series only for letting you know the shortest form is {de'i'u ma}, not {ca de'i li jydy xo}. I don't intend to discuss the current topic for now. Please continue without me.

mu'o

Although I said I don't intend to join the discussion, I change my mind because I observed on bpfk-list a movement toward modifying the grammar around lerfu and numerals. 

https://groups.google.com/d/topic/bpfk-list/GQ9Mnwieue0/discussion

First, creating a convention for a sumti in {de'i/ti'u/te'i} clause is not at all interest me. If we need, we can always specify the structure and meaning of sumti by a {vede'i/veti'u} clause according to official English definition, or by a {tede'i/teti'u/tete'i} clause according to experimental Lojban definition.

Secondly, removing {pi'e}s in li clause is nonsense. Even though {pi'e} separates digits, it denotes one number, on which carrying may occur across {pi'e} in calculation. For example, {de'i li 2015 pi'e 5 pi'e 31 su'i pi'epi'e 1} should mean the same date as {de'i li 2015 pi'e 6 pi'e 1}. In usual mathematical notation and in ISO_8601, a number is represented in the form "higher column to the left". In the case of date, a number [ny:ly:dy] means [365*nyxipy+366*nyxiky]+[29*lyxity+30*lyxixy+31*lyxizy]+dy, where the bases [365/366] [29/30/31] should vary according to a complicated but unique rule. You may change the order of columns "{vede'i lo drata be I'ySyO'y xi 8601}" if you want.

Thirdly, You don't need selma'o LI if you remove {pi'e}: removing {pi'e} breaks separation of digits on different bases. The resulting string of numerals and lerfu is out of mathematical rule. If you once abandon carrying of calculation, you can use raw lerfu as sumti in arbitrary order: {de'i jydyxi2 joi lyxi5 joi dyxi26 joi nyxi2015}. There are no need of modifying grammar.

Sorry for bothering, but I don't understand the reason for modifying grammar for such an indifferent-to-me matter. I would be in favor of modifying grammar if any more important requirement occurred, though,

 

[guskant]

Le mardi 2 juin 2015 17:19:45 UTC, guskant a écrit :

is represented in the form "higher column to the left". In the case of date, a number [ny:ly:dy] means [365*nyxipy+366*nyxiky]+[29*lyxity+30*lyxixy+31*lyxizy]+dy, where the bases [365/366] [29/30/31] should vary according to a complicated but unique rule. You may change the order of columns "{vede'i lo drata be I'ySyO'y xi 8601}" if you

Sorry again, I forgot to write a base 28, o'anai u'i 

[Spheniscine (la zipcpi)]

doi .guskant. :

My system isn't the only system that includes "magic letters" in the dates. Take the following character strings, all with a meaning under ISO 8601:

2015-W22

2015-05-31T19:00:17Z

P3Y6M4DT12H30M5S

[Spheniscine (la zipcpi)]

First one represents week-of-year numbering

Second one uses T as a semantic separator between the date and time, and Z marks UTC time

Third one is period (similar to the kuspe idea I included at the bottom of my proposal): three years, six months, four days, twelve hours, thirty minutes, five seconds.

Really all I did was adapt ISO 8601 to be more usable and flexible as a Lojbanic sub-language.

[guskant]

As I said first, I'm not interested in any convention of the form of sumti in {de'i/ti'u/te'i} clause (sorry for my bad English), and I don't mind if you suggest anything about it unless il will affect my usage of Lojban. In the current case, I was worried about an undesirable modification in grammar, but (.ui) it seems needless anxiety in observing the further messages of the thread:

https://groups.google.com/d/topic/bpfk-list/GQ9Mnwieue0/discussion

By the way, you can specify the system more precisely than {I'ySyO'y xi 8601}, for example:

ex1) tete'i I'ySyO'y xi 8601 joi lo sinxa be lo jeftu ...

ex2) ro detri poi pagbu di'e cu temjudri fi I'ySyO'y xi 8601 joi lo sinxa be lo jeftu .i tu'e ...

ex3) ... ti'o fi I'ySyO'y xi 8601 joi lo sinxa be lo jeftu cu temjudri (se'u) ... (though this usage of ti'o is somehow unexpected in CLL.)

and if once it is declared, you don't need to repeat it in the same context, unless you want to mention a date in another format. Also for the other system, you can specify the system as much precisely as you like, with some mentioning like {porsi fa lo sinxa be lo jeftu ce'o lo djedi}, {lo manri be fi la stani joi jimca} (a calendar according to http://en.wikipedia.org/wiki/Sexagenary_cycle ), etc. The latter uses names of animals instead of numbers, u'ipei.

Anyway, don't mind my rant for now: observing the current movement in the bpfk-list, I'm rather {u'unmo} for posting that.

[Gleki Arxokuna]

2015-06-01 9:54 GMT+03:00 Gleki Arxokuna <gleki.is...@gmail.com>:

2015-05-31 15:32 GMT+03:00 Jorge Llambías <jjlla...@gmail.com>:

On Sun, May 31, 2015 at 9:22 AM, la gleki <gleki.is...@gmail.com> wrote:

Disadvantages:

a. Like it's {pi'e} equivalent it's not a predicate language. An expansion of these rules into predicates is needed for linguistic purposes no matter how verbose the expansion will be (i.e. its value for everyday usage is irrelevant). {citsi} also has to be explained in this expansion since it is one of the few "splicing time interval" brivla. relations like {ca}/date, {ze'a}/period are to be explained.

b. Those are new rules injected into the language. Multiplying entities is usually not good. Although they actually make {pi'e} solution not needed so in total the required part of the language becomes less heavy.

c. timezone can't be easily specified inside {de'i} using names of countries.

d. It will break down if (and hopefully when) digit strings become disentangled from letter strings.

e. To say "Monday" one will have to resort to {se detri be li jydy pa}, not a very short expression, same for months. So to imitate major languages the 7+12 extra words (pavdei, pavmasti etc. or equivalents) might still be needed.

And obviously this doesn't work for non-compatible calendars. E.g. the maya one who literally wrote 13.0.0.0.0 in Long Count.

Again its expansion into mayan units such as k'in, winal, tun etc. are needed. And it's not clearly understandable how to sum up these units. And how to operate different units arithmetically in general.

2 miles + 3 km ~= 6km

li mo'e lo minli be li re te'u su'i mo'e lo ki'otre be li ci ... ?

is it the magic of both minli1, ki'otre1, mo'e and su'i that make those intervals not overlap?

[Oleksii Melnyk]

If mixing PA & BY in LI is such a controversial thing, why not use "la (PA*BY)*" instead? As far, as i (don't really) know that would harm no grammar, and, probably, would be the shortest alternative possible due to frequently skipped 'y's (ignore the wrong, capitalized tags): de'i la renopamuN feiL cipaD, or la reDYpaL, etc.

[Spheniscine (la zipcpi)]

http://mw.lojban.org/index.php?title=loi_lerfu_tcita_detri

Made some additions:

{zy} as abbreviation for {jydy} (derived from {ze});

{xy} for century (derived from {xecto});

Tags for 12-hour times; I strongly prefer 24-hour, but they're there just in case one needs to refer to a 12-hour time without knowing whether it's am or pm;

Ways to turn dates into sumti for time-sumtcita and such.

[Spheniscine (la zipcpi)]

More changes:

• Each tag now has exactly one meaning. {ny} and {dy} no longer change meaning in the presense of {jy}, instead, ISO week dates are prescribed the format {li jyny renonoxa jy mure zy ze} (or {jydy ze}). This allows Gregorian dates and ISO week dates to be combined to a single date without ambiguity.
  
• New tag {xyny} for last two digits of the year, instead of having to use {xo'e} to replace the missing digits.