Ideally, we would accept an optional locale. If no locale was provided we would go up into the document and find the lang attribute and use that as the locale. We would have a listed set of locales that the component supports.

Everything would be based on the locale:

1. order of day/month/year inside the input
2. Month translations
3. Day abbreviations
4. Mon vs. Sun start date for calendar itsself
5. aria labels for "next month" and "previous month"

We could let the user pass in the translations but it would represent a rather huge config object. The localized moment build includes all of these strings, so we can lean on their translations. The only thing I think is missing is the "next month" text. This will be important for screen readers to infer what the caret icons mean. I think we could just have devs pass these in (or just label them with the month it would be if they clicked the caret)

from calcite-design-system.

Like @patrickarlt JS API 4.12 uses native Intl for date formatting. I don't think you will need formatToParts. You can use format to format months directly:

var formatter = new Intl.DateTimeFormat('en-us', {
  month: 'long'
});

formatter.format(new Date()); // June

We only need cldr info to parse dates from strings but if you choose ISO 8601 then you won't need.

And for moment we are removing in all places possible, this convenience brings 50kb of JS which we usually don't need.

from calcite-design-system.

@kumarGayu Feel free to take a crack at these if you have the time 👍

from calcite-design-system.

I am kind of leaning towards using moment for formatting and locale support. does anyone see any problem using moment? because otherwise we might end up having many translation of same thing across the projects. Moment.locales already have the information which I needed.

from calcite-design-system.

I would be pretty strongly against Moment since it is really large and we would have to be REALLY careful about how we include the locales to not bloat bundles and we would have to document how to include the locales in the final apps all of which is complicated and could reduce adoption.

The input date format should always be an ISO 8601 date. The output format and all internal state should be that as well. Since all our internal references are just date objects the rendered UI could possibly be built on top of Intl.DateTimeFormat. Particularly the formatToParts method.

The Intl APIs can be polyfilled with https://github.com/andyearnshaw/Intl.js which could be loaded on the fly for IE 11.

So with the Intl APIs in mind lets looks at @paulcpederson's 5 items:

Order of day/month/year inside the input

var formatter = new Intl.DateTimeFormat('en-us', {
  year: 'numeric',
  month: 'numeric',
  day: 'numeric',
});

var formattedDate = formatter.format(new Date());
console.log(formattedDate); // "6/18/2019"

Month translations

var formatter = new Intl.DateTimeFormat('en-us', {
  month: 'long'
});

var month = formatter.formatToParts(new Date())[0].value;
console.log(month); // "June"

You could execute this in a loop to get the month translations.

Day abbreviations

var formatter = new Intl.DateTimeFormat('en-us', {
  weekday: 'short'
});

var day = formatter.formatToParts(new Date())[0].value;
console.log(day); // "Tue"

You could execute this in a loop to get the day of week translations.

Mon vs. Sun start date for calendar itself

The Intl API doesn't support this yet but there is some old discussion in standards groups about it in tc39/ecma402#6 and tc39/ecma402#46.

However this information is REALLY easily accessible via the CLDR data in https://github.com/unicode-cldr/cldr-core/blob/master/supplemental/weekData.json. We could simply request the data and package it in. For the 40 locales Online supports a object of:

const WEEK_START_DAYS = {
  en: "mon",
  //...
}

Wouldn't be to big, especially if we assume everything starts on Monday except for the few locales where it doesn't.

We could use cldr-data and cldr-js to build a script to extract this for us. We could reuse that same script later if we needed additional things out of CLDR.

aria labels for "next month" and "previous month"

These can be provided by the user via @Prop().

from calcite-design-system.

added time:

from calcite-design-system.

@rmstinson yeah for comps and mockups def that is the correct format.

In the implementation, though, the order of day, month, year should probably be determined by the user's locale. Ie. in Korea the natural format is "YEAR. MONTH. DAY." with periods, it's crazy. Pretty much every country does something different, it's actually kind of insane. Here are some examples: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat#Using_locales

from calcite-design-system.

a week or 2 max.

from calcite-design-system.

Mockups:

cc'ing @kumarGayu

from calcite-design-system.

@kumarGayu, here's a start. (FYI, $shadow-2 is still in the process of being added to calcite-base by Adam and it might be called something different).

from calcite-design-system.

@julio8a Thank you, I started on tsx part will be in touch with you sooner.

from calcite-design-system.

@julio8a, @paulcpederson @macandcheese @patrickarlt are we thinking of localization. rest all the tool we needed that to be fed from consuming app. but for this we at least need these things to be localized (or for now I can make it as fed from outside).

1. Month Name
2. Numbers
3. date format
4. Day name.
   ...

For now, I assume this is coming from the consuming apps. but, we can always turn on locale when we have the decision.

from calcite-design-system.

I would assume we can either... allow folks to explicitly pass the Moment format/s they desire as prop/s, or base the Moment formatting off of a "lang" prop either on the component, the global calcite-config (WIP), or interpreted from the page?

from calcite-design-system.

It is also worth noting here that the JS API team is moving away from things like Moment and toward the Intl APIs wherever possible.

from calcite-design-system.

Using Intl matches the underlying concepts of this repo better, for sure: lightweight, use newer browser standards where possible, etc. I am very into this idea. I have never liked how ginormous moment is, so this seems like a good replacement.

@patrickarlt if we use intl.js polyfill does stencil take care of loading that for IE11?

from calcite-design-system.

@patrickarlt and @ycabon Thank you I will use native intl now. I haven't made use of moment until now.

from calcite-design-system.

if we use intl.js polyfill does stencil take care of loading that for IE11?
@paulcpederson - #58 (comment)

No my preference would personally be to document that if you want fill i18n in IE 11 for <calcite-date-picker> you should load the polyfill and the locale data yourself. Eventually IE 11 will go away and then we don't have to make any code changes here.

We COULD potentially make a loader for the polyfill but it feels really outside the domain of calcite-components since it would load the Intl polyfill for the whole app.

from calcite-design-system.

@patrickarlt that seems reasonable. We will have to make sure to doc that decision. It may be a good idea to have a browser support table in the readme with some notes on this stuff.

from calcite-design-system.

I'm working on a Date/Time format picker for AGOL charts - it might be a good idea to solidify MM/DD/YYYY and H:MM TT (01/24/2009 and 3:45 PM) to be the default format (as shown above)

from calcite-design-system.

Dark theme, I can help with styling:

from calcite-design-system.

😻

from calcite-design-system.

beautyful!

from calcite-design-system.

ccing myself @ekenes since I want to track progress on this for our Smart Mapping workflows in the JS API.

from calcite-design-system.

@julio8a @kumarGayu What is the estimated milestone for this? There are several JS API widgets that would like to take advantage of this component.

from calcite-design-system.

@ekenes Right now i am in training for 2 weeks, but by then whenever i get free time i will make this available. However, now we have the date picker in place for light theme.

from calcite-design-system.

Cool! So date + time picker is already available for light themes?

from calcite-design-system.

Time is not yet there. :(

from calcite-design-system.

Ok. What's the approximate timeline for adding time?

from calcite-design-system.

Hey @kumarGayu - any update on the status of this or the related Edge issue? #137 - thanks in advance!

from calcite-design-system.

A bit of late feedback.

Feedback 1

A the case for a single calendar range selector. For Dashboard UI, the double calendar range selector is over killing. Too much space, etc. I would encourage a more compact range selector relying on a single calendar. You can look at:

• https://ember-power-calendar.com/docs/range-selection

Feedback 2

The case for date pattern. Currently if the calendar is set to French, the placeholder shows: DD/MM/YYYY.

DD, MM, YYYY have only a meaning for english language.
In German DD should TT, in French should be JJ.
My point is this pattern has no meaning outside of english speaking countries and it's inner guts exposed outside.

Feedback 3

I really hope that the calendar is a component by itself and can be decoupled from the click button behavior and hosted in other components such as Modal or just by itself.

Feedback 4

The current calendar is not using calcite colors.

Feedback 5

As I type in the input box a date, the calendar doesn't reflect the date.

from calcite-design-system.

@ffaubry agree on those points - @julio8a can we make some tweaks to support single input range? - would likely just need to update the input area a bit and place some divider or directional indicator between start / end dates.

from calcite-design-system.

One additional consideration might be a slot for range shortcuts? For instance, select yesterday, last week, month etc. A simple example: Link
Monitor's got a bunch of date range selections - we're super interested in this. Looking epic!

from calcite-design-system.

Agree @evanmosby I'd say that's almost expected behavior for many use cases.

from calcite-design-system.

@julio8a can you post the design for single input range selection?

from calcite-design-system.

@paulcpederson could add Ben to this repo?
He will provide our requirements for this.
He has been designing our date UX for dashboard.

from calcite-design-system.

@paulcpederson design for single input range:

@ffaubry, I added Ben to the repo.

from calcite-design-system.

Hi guys, curious as to the timeline on this one. The Monitor product could sure use a date range picker :) We can implement two individual pickers today to get us by, but probably not something we'd wanna ship with. Thanks!

from calcite-design-system.

@julio8a what does the input look like for the range? Also what interaction model should it use? As in, if I click "8" does the range extend to 8 or am I selecting a new range beginning at 8.

As per the API for this, considering aligning this with calcite-slider props. Basically add two props for range:

• minValue
• maxValue

We would then need to change the event detail for the emit on date select to:

e.detail = { min: Date, max: Date }

@macandcheese thoughts on this API?

Because of the rework I did a while back, the range feature should be a lot easier to add now...

from calcite-design-system.

@julio8a also might be worth moving a full spec + designs for range to a new issue as this one is getting a little wacky.

from calcite-design-system.

@paulcpederson API looks good, consistency is 👑 - Agree with a new issue.

from calcite-design-system.

Will do new issue

from calcite-design-system.

The date is in master. I split the range into another issue #541. Closing this one out.

from calcite-design-system.