Draft Feature: Historical Date FIeld

benloh commented 1 week ago

A general date input field that can support a variety of calendar formats for historical projects, e.g. 1000 AD, 10,000 BCE.

The intent is to provide a unstructured input field that allows users to enter arbitrary date-related strings that can be parsed by the application well enough to support filtering and sorting.

This is primarily used for data input rather than timestamping.

The input field itself is intended to be flexible, using the chrono-node library to parse a wide variety of date formats. The component then interprets the parsed date and offers a selection of formats for the user to choose from. The selected format is then displayed in the field. The user has the option to select the format "as entered" or to choose from a list of suggested formats based on the parsed date.

Formats are dynamically generated based on the available parsed date, displaying only formats that match the the parsed dimensions. For example, if the parsed data includes a year, month, and day, the component will offer a variety of formats including "April 1, 2024" and "2024/4/1". If the parsed date only includes a year and month, the component will offer formats like "April 2024" and "2024/4", but not "April 1, 2024" if the day is missing. If the parsed date only includes a year, the component will offer formats like "2024" and "2024 CE", etc.

Eras are handled via a template. The user can set the era to BCE/CE or BC/AD. Dates can be entered in any format, e.g. "2024 BCE", "2024 BC", "2024 CE", but the selected format will use the format defined in the template, e.g. if the eras format is set to "BCE/CE", entering "1024 ad" will be formatted as "1024 CE". (If you select "as entered" as the format you can still use "1024 ad")

For ambiguous years, adding a "CE" or "AD" to the end of the date will clarify the era. For example, "102" can't be parsed, but "102 ad" will parse the input as a year.

You can add extra descriptive text to the field. As long as the field can interpret the date, the exact text doesn't matter. So you can add other descriptive text as part of the field and sorting and filtering should still work. This doesn't work if the input can't be interpreted. And you do have to make sure the interpretation is correct.

The stored value of a historical date field includes:

The raw input string
The selected format The final output is then dynamically generated based on the selection.

Draft Features

This is a work in progress.

In the current iteration, the app will inject a historical date field into any node so that you can play with how dates inputs are handled. The demo date fields currently do not save data. But you can enter date strings and review how the date is interpreted.

Currently eras are hardcoded as "BCE/CE". Eventually the template system will allow entering "BC/AD" or other designators for years before and after 0.

In the final version, dates fields can be defined via the template anywhere in the app (e.g. as a node or edge field or a provenance field).

To Test

The main thing to test right now is to focus on whether or not this method of entering dates is workable for historical projects. Would it be simpler/easier/better to just force year, month, day, era selections? Or is it useful to able to support arbitrary strings that are interpreted and formatted in a variety of ways?

git checkout dev-bl/historicaldate
nvm use && npm ci -- new libraries have been added
npm run dev -- Any project should work.
Log into the network, and create a node.
Select the node
Note that there is a "Date" field set to "apr 2024" -- this is currently hard coded.
Click "Edit" to edit the date field.
Try editing the date, e.g. add a "1", change the date to "4/2024" etc. -- The app will show an interpretation of the date (e.g. "month: 4 year: 2024")
Select the "Format" menu to see the optional formats for the date.
Select a format. Note the "Result" field now shows the selected format. (We can probably simplify this to just show the selected menu item). -- The format options are based on the data that is available. e.g. if the system can't find a year, then formats with years are not shown.
Enter "ad" or "bc" or "bce" to enter era info.
Try adding or removing data (e.g. remove month, remove year, add day, etc)
Try adding arbitrary text, e.g. "circa 1500 AD".
Try entering ambiguous data, e.g. how do you enter the year 10 vs 2010.

Examples:

apr
april
apr 2
4/2
2 apr
2/2/22 -- interprets this as 2022
around 100 ad

Sometimes the system can't interpret the data. e.g. it's not clear if a two digit number refers to a day or a month or a year. Usually if you add more identifiers, the system will be able to interpret the date. e.g.:

100 ad
jan 1 100 bc

Please play with it to see what you think. Hopefully this feels more natural and is flexible.

Questions

[ ] Do we need to support times? timezones?
[ ] Do we need to explicitly support calendars? e.g. add a field to select "Hebrew" or "Chinese" or "Gregorian" calendars?
[ ] Should the format be always selectable, even when not in edit mode? e.g. if I open a node, the date would show the stored selected format. You can change the format only if you edit the node. This simplifies the interface (you don't need to have an extra menu to select the format in "view" mode.) OTOH I can see how it could be helpful for some students to be able to view the date in a different format.

jdanish commented 3 days ago

I ran nvm use and npm ci and even tried clearing the cache but I keep getting this error. Is there some other way to force the install or maybe something not committed yet?

jdanish commented 3 days ago

Do we need to support times? timezones?

No.

Do we need to explicitly support calendars? e.g. add a field to select "Hebrew" or "Chinese" or "Gregorian" calendars?

I assume whoever edits the template will build it to reflect the calendar that that field always uses and indicate that in the held text for the field if needed. I assume that if field A is set to effectively be "Gregorian" then Kalani has a date in a "Chinese" calendar format, it's her problem to translate before data entry. We don't want to get into the game of having her say "this is Chinese" and translate on the fly for her. At least, not for the current student-focused implementation (and I don't anticipate anytime soon).

Should the format be always selectable, even when not in edit mode? e.g. if I open a node, the date would show the stored selected format. You can change the format only if you edit the node. This simplifies the interface (you don't need to have an extra menu to select the format in "view" mode.) OTOH I can see how it could be helpful for some students to be able to view the date in a different format.

That sounds right to me.

@kalanicraig speak now or ... well wait until the next grant if any of this doesn't work.

kalanicraig commented 3 days ago

Agreed on all points. On date standardization: Most projects will standardize to a single date type and convert anything internal, and we have a notes field to disambiguate outliers and odd dates. On live date conversion: no. Editing only; Joshua’s exactly right that we don’t need that kind of complexity.

On Mon, Jul 1, 2024 at 8:35 AM Joshua Danish @.***> wrote:

Do we need to support times? timezones?

No.

Do we need to explicitly support calendars? e.g. add a field to select "Hebrew" or "Chinese" or "Gregorian" calendars?

I assume whoever edits the template will build it to reflect the calendar that that field always uses and indicate that in the held text for the field if needed. I assume that if field A is set to effectively be "Gregorian" then Kalani has a date in a "Chinese" calendar format, it's her problem to translate before data entry. We don't want to get into the game of having her say "this is Chinese" and translate on the fly for her. At least, not for the current student-focused implementation (and I don't anticipate anytime soon).

Should the format be always selectable, even when not in edit mode? e.g. if I open a node, the date would show the stored selected format. You can change the format only if you edit the node. This simplifies the interface (you don't need to have an extra menu to select the format in "view" mode.) OTOH I can see how it could be helpful for some students to be able to view the date in a different format.

That sounds right to me.

@kalanicraig https://github.com/kalanicraig speak now or ... well wait until the next grant if any of this doesn't work.

— Reply to this email directly, view it on GitHub https://github.com/netcreateorg/netcreate-itest/pull/228#issuecomment-2200028796, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACKL4NEPUPQLYXAIS4RDP3TZKFEIBAVCNFSM6AAAAABJ43FYW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBQGAZDQNZZGY . You are receiving this because you were mentioned.Message ID: @.***>

netcreateorg / netcreate-itest