Automatic date/time extraction from user input like messages, notes, or descriptions.
Handles time zones & loacles for global apps, ensuring accurate date handling across regions.
Server-side action to parse dates from the backend (costs about 2 WU) (or from the front-end if you really want to)
Custom date format detection that allows you to either extract automatically, or specifcy the date/time structure, useful when you know how it is always structured.
Use Cases:
Automatically pull dates from free text (e.g., āLetās meet on July 16 at 3PMā).
Convert any ātextā date (that Bubble canāt deal with) back into a date/time value useful for Bubble.
Handle dates in different languages and time zones with ease.
from the code: //If time is not specified in the dateTemplate, default to 00:00 luxon does that for you already (e.g. luxon.DateTime.fromFormat("September 11 2024", "LLLL dd yyyy"); is already a date with time Wed Sep 11 2024 00:00:00 GMT+0100, plus the test for hasTime will return true even if one of the characters is included in your custom templating escape system but then itās removed from the final template
your custom regex parsing is actually not 100% compatible with luxon tokens for parsing, some tokens are not supported in luxon (e.g. ZZZZ) and others are supported in luxon but missing in yours (e.g. EEEEluxon.DateTime.fromFormat("September Wednesday 11 2024", "LLLL EEEE dd yyyy") is correctly parsed by luxon, but in the demo page itās not). in both cases the plugin returns no parsed date without providing any error.
a complete lack of error communication sets you up for a really bad developer experience, expecially when trying to debug unparsable templates. luxon returns some nice errors and it can be very helpful to either expose them in a plugin variable to use in the editor or at least enable debug logs in preview mode.
Thank you! Will take a look and improve these! For error handling, I planned for people to just use the demo to debug things live, but can see that extra info might be helpful!
On the time defaulting to 00:00 - when testing, the time was defaulting to 12:00 in UTC or the specified timezone, hence adding this. Donāt know why that was happening if Luxon also defaults it to 00:00, because it wasnāt before. I changed from moment.js ā Luxon, so maybe itās a remnant of that which didnāt default.
For certain tokens not being handled, it may be because theyāre formatting tokens rather than standalone tokens. Would probably make sense to add these too.
Thanks for this plugin George, itās really useful! Iām trying to use it with a date stored as a Unix timestamp in milliseconds, but I canāt seem to get it to work. Does it support this format?