You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of the DateTimeControl does not allow for configuring the default timezone in any manner. It also does not allow the end user to BTODL (bring their own date library). The AntD DatePicker allows for using custom date libraries if the consumer prefers something like moment, date-fns or luxon.
The complications of trying to implement this inside the library in its current form come in 2 flavors.
The user will need to supply a config object to the component for their library of choice so we can use DatePicker. generatePicker(<userConfig>). This can be made generic in component relatively easy via the GenerateConfighelper fromrc-picker`.
The jsonforms field that we are targeting with this control is a string formatted as a datetime. This means that the value coming in from the form's data or initialValue need to be parsed from a string into the relevant flavor of date object for their library of choice (antd uses dayjs by default, which is why that is what is used in that first implementation). This means that along with the config object for the form the end user will need to supply a parse function to convert the datetime string into their (potentially timezone aware/included) date library object. Maybe something along the lines of:
...
importtype{GenerateConfig}from'rc-picker/lib/generate'importgeneratePickerfrom'antd/es/date-picker/generatePicker'importdayjsGenerateConfigfrom'rc-picker/lib/generate/dayjs'importdayjsfrom'dayjs'importtype{Dayjs}from"dayjs"typeDateTimeConfig<T>={generateConfig: GenerateConfig<T>/** * Parse a string value into the date type expected by the generate config */parseDate: (dateString: string)=>Ttimezone?: stringformat?: string}typeControlProps=Omit<JSFControlProps,"uischema">&{uischema: ControlUISchema<unknown>&{options?: DateTimeControlOptions&{dateConfig?: DateTimeConfig<any>}}}constDEFAULT_PROPS: DateTimeControlOptions={format: {format: "YYYY-MM-DD HH:mm:ss",type: "mask"},}asconst// Default config using dayjsconstdefaultDateConfig: DateTimeConfig<Dayjs>={generateConfig: dayjsGenerateConfig,parseDate: (dateString: string)=>dayjs(dateString),}...exportfunctionDateTimeControl({
...
// Use provided generate config to create pickerconstDatePicker=generatePicker(dateConfig.generateConfig)// Parse initial value using the provided parserconstinitialValue=schema.default ?
dateConfig.parseDate(schema.defaultasstring) :
undefined...
The types here would really need to go in ui-schemas with the rest of the DateTimeControlOptions but this shoule convey the idea.
The text was updated successfully, but these errors were encountered:
ashmortar
changed the title
Add support for configurable default timezones
Add support for configurable default timezones and other Date Libraries
Oct 23, 2024
The current implementation of the DateTimeControl does not allow for configuring the default timezone in any manner. It also does not allow the end user to BTODL (bring their own date library). The AntD DatePicker allows for using custom date libraries if the consumer prefers something like moment, date-fns or luxon.
The complications of trying to implement this inside the library in its current form come in 2 flavors.
DatePicker. generatePicker(<userConfig>). This can be made generic in component relatively easy via the
GenerateConfighelper from
rc-picker`.string
formatted as adatetime
. This means that the value coming in from the form's data orinitialValue
need to be parsed from a string into the relevant flavor of date object for their library of choice (antd uses dayjs by default, which is why that is what is used in that first implementation). This means that along with the config object for the form the end user will need to supply a parse function to convert the datetime string into their (potentially timezone aware/included) date library object. Maybe something along the lines of:The types here would really need to go in
ui-schemas
with the rest of the DateTimeControlOptions but this shoule convey the idea.The text was updated successfully, but these errors were encountered: