1073 enable date/time pattern selection through ColumnSettings

[junaidzm13]

• converges date and time column types to one unified date/time type, consistent
  with how some major programming languages handles datetime.
• date/time pattern selection is only available for columns with "date/time" type.
• changes DateTimePattern to be an object instead of strings to enable
  simultaneous selection of both date and time patterns.
• also moves DateTimeColumnDescriptor to vuu-table-types package for consistency.

[netlify]

✅ Deploy Preview for papaya-valkyrie-395400 canceled.

Name	Link
🔨 Latest commit	f227c9f
🔍 Latest deploy log	https://app.netlify.com/sites/papaya-valkyrie-395400/deploys/6593ef8080db2e0008cd30f5

[junaidzm13]

Here's how the UI looks:

Looking good. Consider also the scenario where column has no existing configuration (just a plain old long) and we want to assign date/time here.

[heswell]

somewhere we ought to warn the user if they do something invalid, like assigning a date/time type to a column with a serverDatatype that is not long. This is part of the weird dissonance arising out of the fact that we're mixing server assigned data types and client side config.

Maybe we ignore for now and assume we'll fix all this when we overhaul the metadata sent by server.

[heswell]

This is good but there's still a gap in functionality. We're showing the data/time config settings if the column has already been configured as a
date/time type. But the config settings panel should be where we can actually assign date/time as the type to a column of type long

I see two possibilities

1. we populate the renderer dropdown with an alternative to the 'default long renderer', we add a 'default date/time' renderer. This would assign the date/time type to a long column.
   technically we're not actually implementing a renderer, just a formatter.

2. We add an additional UI item, to allow toggle on a long column, so user can pick between number or date/time When thet switch to date/time, we render the new settings

wdyt ?

[junaidzm13]

Yeah that's true. To me the second option sounds better (though the first one seems easier to implement, second might need passing down a separate action handler for handling type change).

Mixing up renderers with formatters could end up confusing devs, and it could also be harder for the users to navigate in case we have many renderers.

[heswell]

all looks good. Need to add the ability to switch a long to data/time in the settings panel.
I'd suggest adding a few date and time columns to instruments-extended in the test data package) Thats where we added stuff to test the boolean columns - I extracted these to instruments-extended rather than leave them in instruments when I realized later that the extra columns broke some existing stuff. Now that instruments-extended isd a separate table, we can add anything we want.
If you view it in Tables/SIMUL/InstrumentsExtended in showcase, you can bring up the ColumnSettings -

[junaidzm13]

This is how the table/settings look:

• I've also edited InputCell to use unformatted values when editing, since users would ideally want to edit the original data not the formatted one. Found the issue when I tried editing a date (long timestamp). (Separate commit)

• Also updated the available cell renderers for boolean columns (Separate commit)

[heswell]

looks good, plus tested it locally