I've raised a PR that adds the ability to select a format for the timestamp option in the Inject node (and Change node... and any other node using the built-in TypedInput).
Currently, the timestamp option generates a value that is milliseconds since epoch. A common scenario we see is Function nodes then being used to reformat that into some other common representation.
To keep things simple, I'm proposing to offer a short list of commonly useful formats. I'm inviting feedback from the community on what options should be on the list.
Before anyone suggests it, it is feasible to add a 'custom' option that lets the user enter the format string manually... but before going that route, I'd like to make sure we have a good set of built-in choices.
Localisation is a bit of a tricky subject as it requires the node.js runtime locale to be set properly for the end user. That isn't always going to be the case - a cloud hosted instance for example will typically have a locale different to the end user.
It is the type of can-of-worms I'm hoping to avoid for this quick feature
UTC - we should encourage UTC use mostly since it avoids processing issues. If people have easy options to use local, they are likely to use it and get caught out in the usual date/time processing gotya's.
And yes, I'm aware of the irony of me of all people asking for simplicity!
My preference would be local timezone - For me, If I would be using this capability it would be for easy viewing of dates, It would reduce the cognitive load to have it in local time. If I want to do UTC things then i take the time stamp and process it.
We are operating in different time zones so plain local without time zone context has no meaning to us, therefore ISO8601. And if that is in Zulu or Local or whichever timezone doesn't matter, as long as we have that timezone information. (But I'd prefer Zulu time...)
In ISO8601 you have the time zone designator. It can be "Z" for Zulu time (aka UTC) or an offset from UTC. If you omit this zone designator, you should assume that the time is in local time. But then you have no information of what local time, i.e., what the offset from UTC is for that time.
So by omitting time zone designator you get the local time, but without info on what local time.
This is great! After thinking about it a bit, I think that using UTC for these formatting options will only lead to more function nodes, so locale should be used. If the system locale is not set correctly and cannot be changed, or if this is for an app that would have users from different locales, that should be handled the current way through dashboard templates etc.