pjanik
commented
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.
codecov[bot]
cypress[bot]
bfinzer
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.