Localize dates and times based on the device's locale
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- javascript
- Domain
- localization, mobile-dev
Research direction
Start by locating the app's date and time formatting entry points, then review navigator.globalization.dateToString and getDatePattern. Compare the options with the UTR#35 and Cordova references in the issue. Done means dates and times follow the device locale, including locale-appropriate ordering and time formatting.
Written by the indexing model from the issue text.
Description
All of the dates in the app are shown with the day preceding the month in the way the majority of the world expresses it. However Americans think this format looks odd and may lead to confusion where both the day and the month are less than 12. Textual labels (e.g. "Jan") could possibly eliminate some of this confusion. Rather than managing the date format in the conference config, the app should instead load the device's locale settings and format dates accordingly which is especially useful for conferences that draw worldwide attendance. This has the added benefit of using the device's time formatting. While 12-hour format is generally acceptable, many programmers--who seem to be the prime audience to the apps that have been deployed thus far--may prefer 24-hour format.
cordova-plugin-globalization offers the navigator.globalization.dateToString function which is ideally suited to this task. Its only downsides are that it requires round-tripping to the native side and that it is asynchronous (making the calling code unnecessarily complex).
Alternatively, navigator.globalization.getDatePattern() could be loaded once (and stored per session) to avoid the round-tripping to the native side. However this may not be an ideal solution as I have yet to find a JS library that fully conforms to the UTR#35 spec, let alone one that is localized (fecha was the closest). Additionally, this function has a critical open issue.
- Dominant language
- JavaScript
- Stars
- 10
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from eclipsesource/tabris-con
-
Battery drainageOpenbug
Difficulty 5/5 Over a week Newbie friendliness 15/100
eclipsesource/tabris-con#61 ·
-
feature
Difficulty 3/5 1-2 days Newbie friendliness 35/100
eclipsesource/tabris-con#60 ·
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 48/100
eclipsesource/tabris-con#57 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
eclipsesource/tabris-con#56 ·
-
feature
Difficulty 3/5 1-2 days Newbie friendliness 45/100
eclipsesource/tabris-con#55 ·
All issues in eclipsesource/tabris-con
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
arfct/timezone.fyi#19 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
fastify/fastify-http-proxy#493 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
tensorflow/tfjs#8754 ·
-
bug main ui
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
openhab/openhab-webui#4671 ·
Maintainers usually reply within 1 day
-
scratch-paint's npm test does not run lint, so CI never lints paint; one lint error is currently in developPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
scratchfoundation/scratch-editor#754 ·
Maintainers usually reply within 1 day