Skip to content

DatePicker: Improve platform support parity #337

@stackotter

Description

@stackotter

From #244;

Each backend has its own shortcomings:

  • UIKitBackend has weird availability constraints on each picker style, doesn't support hourMinuteAndSecond, and doesn't respect font color
    • Furthermore, UIDatePicker doesn't exist on tvOS
  • AppKitBackend doesn't support the wheel picker style
  • WinUIBackend doesn't support hourMinuteAndSecond, doesn't respect font color, and doesn't respect environment.timeZone (instead always using the current time zone)
  • GtkBackend only supports the graphical picker style, doesn't respect environment.timeZone (instead always using the current time zone), and only supports picking the date, not the time

Some of these are likely less important to fix, or just not possible to fix without reimplementing the native controls from scratch, but there are definitely improvements that we can make.

My priority would be to make sure that all backends support have at least one style that supports editing a date and time, down to the second, and returning the result in the timezone that the picker is displaying the date with.

The last part should be easy enough to implement by using environment.timeZone and updating DatePicker to convert the selected date to the user's time zone before passing it to the supplied binding.

As long as it's clearly documented which styles are supported on each platform, I'm ok with having some styles not supported on certain platforms; especially where they wouldn't be remotely idiomatic.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions