Closed pjanik closed 1 month ago
Right now, I'm leaning towards reverting this change, as we have number-based equivalents of these functions that can be used in other formulas. Variants that return names could be treated as ones useful for the final output.
It's interesting whether anyone actually used these functions in other formula calculations. If that is the case, we could either break or fix these documents with this updated approach. But it's impossible to say.
Attention: Patch coverage is 98.48485%
with 1 line
in your changes missing coverage. Please review.
Project coverage is 85.72%. Comparing base (
430e488
) to head (3a59eef
).
Files | Patch % | Lines |
---|---|---|
v3/src/utilities/date-utils.ts | 96.87% | 1 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
![]() |
![]() |
![]() |
![]() |
![]() |
Details:
Merge pull request #1368 from concord-consortium/187799270-date-formulas-2 | |||
Project: codap-v3 | Commit: 9f88e7dafc |
||
Status: Passed | Duration: 11:02 💡 | ||
Started: Jul 23, 2024 12:54 PM | Ended: Jul 23, 2024 1:06 PM |
View
Output
Test | Artifacts | |
---|---|---|
Graph UI > graph inspector panel > change points in table and check for autoscale |
Test Replay
Screenshots
|
Regarding monthName()
and dayOfWeekName
: These are most often used to create a categorical attribute that can be displayed on a graph or map to help a user understand the data. Thus local language is most helpful for this purpose. Using the result in a formula would be rare, and, as you note, better done with numeric values. So I vote for keeping V2 behavior.
I just pushed a commit that reverts my change and restores V2 behavior. So, I'm merging this PR.
https://www.pivotaltracker.com/story/show/187799270
This PR adds most of the date-related formula implementations. I've also extracted
createDate
(essentially making thedate()
formula reuse it 100%, in contrast to the V2 pattern) andconvertToDate
.One breaking change compared to V2 is that formulas returning the day or month name now always do so in English. V2 would return these in the local language. On one hand, that's useful. On the other hand, it prevents users from using this value in further calculations (e.g.,
if (...)
). However, if necessary, users can always use formulas that return numeric values. So I wonder if I should actually change it or not.Finally, the only formula not implemented yet is
seconds
. This one revealed an issue in the current approach, where dates are converted to strings too early, causing the seconds to be lost in the default date formatting. I'll work on that tomorrow. However, I'm not sure if this is going to be a bigger issue.seconds(date(2020, 5, 4, 3, 2, 1))
should be relatively easy to fix. However,seconds(other_attribute_with_formatted_date)
might be much harder (or even impossible) with the current approach where attribute values are always strings and formulas store their results in attribute values.