http://coldfusion.com logo
Join Slack
Powered by
Time for a thread! What should we call this shortc...
# lucee
z
Time for a thread! What should we call this shortcut https://luceeserver.atlassian.net/browse/LDEV-2131
b
I'm not quite clear what the question is
Are we taking about a new member function on dates, or a mast value to 
dateTimeFormat()
, etc?
z
b
Maybe you could suggest a few options on the ticket so that's a bit clearer?
So we're talking about adding to this list, right?
The following masks can be used to format the full date and time and may not be combined with other masks:
• `short`: equivalent to "m/d/y h:nn tt"
• `medium`: equivalent to "mmm d, yyyy hnnss tt"
• `long`: medium followed by three-letter time zone; i.e. "mmmm d, yyyy hnnss tt zzz"
• `full`: equivalent to "dddd, mmmm d, yyyy hnnss tt zz"
• `ISO8601`/`ISO`: equivalent to "yyyy-mm-dd'T'HHnnssXXX"
z
Javascript? Js-iso, js-compat
On my phone
b
Got it, I'm curious if there is a standard or name for the format JS uses. I'd have to research unless someone knows and can chime in
I assume whatever standard JS is using isn't specific to JS, but perhaps it is...
Also, I'm not quite clear-- is the example shown in the ticket what JS does or what ISO does?
Oh, I think I see the difference
Copy code
ssZ
vs
Copy code
ss.SSSZ
?
So actual examples would be: • ISO - 
2022-08-18T11:08:51-0700
• JS - 
2022-08-18T11:08:01.001-0700
m
is the difference only the inclusion of milliseconds? It seems like the standard may allow for that, as a matter of precision.
From the wikipedia page:
• If necessary for a particular application, the standard supports the addition of a decimal fraction to the smallest time value in the representation.
and
For example, in Microsoft SQL Server, the precision of a decimal fraction is 3 for a DATETIME, i.e., "yyyy-mm-ddThhmmss[.mmm]"
Seems like the inclusion of MS is not JS specific either. Along with the mention of SQL Server, a quick searched should that Python also includes MS (with further precision):
In Python ISO 8601 date is represented in 
YYYY-MM-DDTHH:MM:SS.mmmmmm
format. For example, May 18, 2022, is represented as 2022-05-18T114022.519222.
Sorry if that all just muddies the water
Just gonna throw out `ISOms`as a mask for iso with ms precision
b
I recommend 
ISOPython
as it's cleary a Py standard 😆
Seriously though, if there's not a name for the standard, and it's simply ISO, but with ms, then I think 
ISOms
good
a
Not that one should follow Haskell, but they have this differentiation: https://hackage.haskell.org/package/iso8601-time-0.1.5/docs/Data-Time-ISO8601.html 
formatISO8601
and 
formatISO8601Millis
(and indeed they also cover µs, ns and ps... so maybe an 
ms
suffix is not so cool in case the need to do microseconds coms along and one would then need to us 
µs
which is a pain to type 😉) Oh they also have 
formatISO8601Javascript
. But... perhaps ill-advisedly for reasons mentioned above.
b
Meh, you could just write the actual mast form memory by then 😆
a
all I was really meaning is that 
ms
might be short-sighted because of [all those words I typed for the reason of explaining] So perhaps 
iso8601millis
. Just 
iso
is perhaps a bit brief cos there's more than one ISO date format. However if there's already 
iso
, then maybe 
isomillis
. Also: it is not a race to save keystrokes. The intent is to make the code clear. One could type out 
YYYY-MM-DDTHH;MM:SS.lll
(without checking closely: did I get that right?), but it's not clear one is specifically meaning "the prescribed ISO-8601 standard format with milliseconds precision". You know... the reason one generally gives a helpful label to values 😐
b
Yeah, calling anything ISO is always funny since that's just the family of standards, but doesn't really tell you which one. It's about a general as saying "RFC"
a
hahahahaha
But do I understand correctly that Lucee already uses 
iso
to mean "ISO 8601 [without milliseconds]", and this is for "ISO 8601 [with milliseconds]"? In which case I say it's too late to fix 
iso
, and 
isoMillis
migth be better than 
isoms
. I'm overthinking now, but some ppl might read that as "eye-soms?" Wazzat? LDEV-2131 is really poorly written, so it's unclear what the actual question is.
Oh hang on... https://docs.lucee.org/reference/functions/datetimeformat.html... right so they have 
iso
and 
iso8601
. In that case I'd do two things: • deprecate 
iso
for the reasons discussed; • add 
iso8601millis
. Not perfect sounding, but - IMO-only - is marginally preferable to 
isoms
. Be thankful I am resisting suggesting 
ISO8601WithMillis
, which is probably what I'd implement.
z
what? mr anti depreication, hashtag lucee can't do anything acf doesn't wants to deprecate iso... yeah nah
ok, I think isomillis, isoMs and javascript sound pretty good ( we often support multiple aliases ), and this leaves code style up to the developer and internal batteles about coding standards with orgs and projects 😉
a
Oh I didn't realise you inherited that from CF. Sigh. OK. I am not against deprecation. I've tried to get CF to deprecate tags in CFML! I am very pro both deprecation and then actually removing shit from the language causing breaking in major releases. It just needs to be handled well and documented well. And I only mean in CF's CFML. I am against Lucee's cack-handed way of using the notion of "deprecation", especially when - as you indicate - it diverges from how CF behaves. Still: OT for this conversation. And if it was down to me you'd not be adding shit into Lucee that wasn't already in CF, but given you insist on doing so, I thought I'd help the discussion to do a decent job of it. The question was, after all, "help with some naming here" ("OK I will"), not "should we even do this" ("no").
So. given there's a hard and immutable precedent of 
iso
then perhaps 
isoMillis
.
Open in Slack
PreviousNext
Powered by