Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support datetime data properly for Line & Bar & Area charts #217

Closed
mia-mifeng opened this issue Apr 2, 2024 · 3 comments · Fixed by #245
Closed

Support datetime data properly for Line & Bar & Area charts #217

mia-mifeng opened this issue Apr 2, 2024 · 3 comments · Fixed by #245
Labels
enhancement New feature or request

Comments

@mia-mifeng
Copy link
Collaborator

mia-mifeng commented Apr 2, 2024

Provide a general summary of the feature here

Currently for line, bar, and area charts, data with datetime format will have to be converted into unix/epoch time stamp format (eg, 1712096542) and be manually sorted in order to be properly visualized. See the date format in the tooltip below:
image

The request is to have the charts to accept a wider range of datetime formats including:

  • ISO8601 2020-07-10 15:00:00.000
  • ISO8601 in UTC 2019-11-14T00:55:31.820Z
    Additionally, the datetime data can be automatically sorted in the chart.

🤔 Expected Behavior?

Line, bar and area charts can properly interpret and display a wider range of datetime formats including ISO8601 and UTC time and can be automatically sorted in the chart as mentioned above.

💁 Possible Solution

No response

🔦 Context

This feature is needed for migrating the UDD charts to use RSC.
Analysis doc: https://wiki.corp.adobe.com/pages/viewpage.action?spaceKey=AEPLT&title=UDD+Charts+RSC+Migration+Analysis

💻 Examples

No response

🧢 Your Company/Team

Adobe/AEP Reporting Experience

@matthewdeutsch matthewdeutsch added enhancement New feature or request needs grooming Issue is pending grooming by the core team labels Apr 8, 2024
@marshallpete
Copy link
Member

For this one it would be best to look at what types of datetime formats react-vega supports. I assume they support more than RSC does so it would be good to look at the specs they produce to see how they are doing it in vega. Once you have the implementation in vega figured out, it should be straight forward to implement in RSC.

Currently we add a time transform to the source data when setting up the data for the given chart type (See lineSpecBuilder.ts line 92, scatterSpecBuilder.ts line 102, areaSpecBuilder.ts line 98).

@marshallpete
Copy link
Member

addTimeTransform in dataUtils.ts is how we currently handle datetime formats and it only works for epoch as called out above.

Ideally there should not be an API change for this ticket. Hopefully the solution will be able to handle any datetime format without the user having to specify which datetime format is being used. Let me know if this isn't possible and wee can figure out a suitable API.

@marshallpete marshallpete removed the needs grooming Issue is pending grooming by the core team label Apr 15, 2024
@mia-mifeng
Copy link
Collaborator Author

mia-mifeng commented Apr 15, 2024

Thank you @marshallpete for the instructions! I made an attempt to fixing this, basically by adding one more entry to transform to convert the datetime field of any format to "Date" in vega:

                {
                  "type": "formula",
                  "expr": "toDate(datum[\"datetime\"])",
                  "as": "datetime"
                },

The actual fix is in this PR #245.
Would you please take a look and let me know if the fix looks appropriate? Thank you!

PS: i double checked that react-vega uses vega-lite which automatically supports various datetime formats. And vega-lite uses the above approach to parse date (source1, source2)

Here're the screenshots -- before the fix
image

after the fix
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants