View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002713 | HTML & PERL | Feature Request - Interface | public | 2016-11-17 02:26 | 2016-11-24 16:47 |
| Reporter | Hinoe | Assigned To | DerIdiot | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 2016-12 | ||||
| Summary | 0002713: Autoconvert character birth/death dates from Japanese format to dd.mm.yyyy | ||||
| Description | Currently, inserting YYYY年MM月DD日 (a date in the Western calendar, but in the Japanese format) as a character birth/death date means the date will be taken literally, as free text, rather than being interpreted as a date in our calendar. This is less than ideal because copying a character birth/death date from a Japanese source is both faster and a lot less error-prone than retyping it in another format. The date should instead be interpreted into DD.MM.YYYY. I tried to figure out a situation in which keeping the Japanese format is desirable, to try and see whether I would be breaking something with my request, but I didn't find anything. YYYY年MM月DD日 and DD.MM.YYYY say literally the same thing even in a world where the calendar doesn't match ours. If you insert 200年21月78日, it should be equally turned into 78.21.200; there is no issue with that, neither should there be one. In fact, it stands to reason that people would convert those manually themselves to begin with. If there is anything _aside_ the Japanese format in the field, spaces/tabs/etc aside, _then_ it should not be converted; in such a case, it should be fine to keep it as freetext instead, the same way as today. In the event the date _should_ be converted nevertheless, we can do it manually. The objective is to simplify the behavior for dates from our world and given in our calendar but in Japanese format, while not breaking anything else, not to cover every case; those our-world dates are extremely common already. As an extra, dates given as MM月DD日 should be converted to DD.MM.????, and I guess that's the only subset conversion that makes sense. Also, currently present dates, if any, should probably be converted as well. | ||||
| Tags | No tags attached. | ||||
|
|
On second thought, YYYY年 to ??.??.YYYY conversions also make sense, so might as well convert any subset already. I mean, dates like DD.??.YYYY and ??.MM.???? make little sense, but if they're valid in the context, we might as well convert the equivalent Japanese format into the standard one. |
|
|
uhm character birth/death dates are _always_ text. there is no conversion there. |
|
|
Oh, I see; I misunderstood what the text on the character edit page meant. In any case, I think we'll agree that YYYY年MM月DD日 and DD.MM.YYYY are literally the same thing, just written in different formats, right? This means that you can read this request the following way: instead of storing "YYYY年MM月DD日" as text, turn it into "DD.MM.YYYY" and then store _that_ as text. It's easier to handle dates taken from Japanese sources if this preprocessing is done by the website (we'd do it manually already to begin with) and there is no use case (none that I can figure out, in any event) for keeping it in the Japanese format. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-11-17 02:26 | Hinoe | New Issue | |
| 2016-11-17 02:31 | Hinoe | Note Added: 0003919 | |
| 2016-11-24 12:21 | DerIdiot | Note Added: 0003926 | |
| 2016-11-24 15:47 | Hinoe | Note Added: 0003928 | |
| 2016-11-24 16:47 | DerIdiot | Assigned To | => DerIdiot |
| 2016-11-24 16:47 | DerIdiot | Status | new => resolved |
| 2016-11-24 16:47 | DerIdiot | Resolution | open => fixed |
| 2016-11-24 16:47 | DerIdiot | Fixed in Version | => 2016-12 |
