[Feature Request] Handling optional parts in date format
See original GitHub issueHello,
I think It could be a nice feature to handle optional parts in date format with []
For example in my case, I can have DateTime with second fractions or not (it’s adaptive).
Actually, I need to perform a Substr
:
FromDateTime(Substr(JSONPATH(payload, '$.created_at'), 0, 18), 'yyyy-MM-dd''T''HH:mm:ss')
But It could be handled like that :
FromDateTime(JSONPATH(payload, '$.created_at'), 'yyyy-MM-dd''T''HH:mm:ss[.SSS]''Z''')
It’s already provided by Java 8 and DateTimeFormatter, in documentation we have :
[ optional section start
] optional section end
Issue Analytics
- State:
- Created a year ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
Ability to have optional parameters in the parse format string
So using regex's ? for an example, the timezone would be optional for checking if a date is valid. Another way to do...
Read more >Date-Input Form Fields: UX Design Guidelines
Summary: Date-entry fields must be unambiguous and support task completion by using the right design pattern. Small design changes can prevent ...
Read more >Control data entry formats with input masks - Microsoft Support
Input masks are made up one mandatory part and two optional parts, and each part is separated by a semicolon. The purpose of...
Read more >Date and time - The Modern JavaScript Tutorial
We can always create a date from a timestamp using new ... The optional 'Z' part denotes the time zone in the format...
Read more >Timestamps, Time Zones, Time Ranges, and Date Formats
The timestamp is parsed either using the default timestamp parsing settings, or a custom format that you specify, including the time zone.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
The above benchmarks were for Java 11. For Java 17, they seem much closer. And converting String to Epoch is actually faster with
java.time
Case in point, I found that Joda was 6x faster than Java time for year conversion here: https://github.com/apache/pinot/pull/8397#issuecomment-1077589112
There has been some progress in java.time recently:
Some of these improvements will be backported to JDK17, so we should reassess once Pinot can run on JDK17.