"Idiomatic CFML" question. I'm needing to do some Calendar (

java.util.GregorianCalendar

) operations, which results in a value I need being a

java.util.Date

. I can't be sure what's going to happen with this value, and it could possibly end up having CFML datetime methods being called on it (eg:

myDate.year()

etc). What's the most idiomatic way of forcing the

java.util.Date

back to a native Lucee date? My thought is

DateAdd("s", 0, myDate)

, and whilst that works, it's not immediately clear in the code why I'm doing that. I'm not adverse to an explanatory comment in this case, but it got me wondering if there's a more "idiomatic CFML" way of doing this?

internally in lucee that would be Caster.toDate()

I don't follow how that helps answer my question?

I would personally if there was not a native clear way create a util function that is called that itself becomes the clear way and is commented about what the abstracted way is... if that makes sense... so something that either points to your simplistic DateAdd .. or something that points to the much more uglier..

createObject("java", "lucee.runtime.type.dt.DateTimeImpl").init(javaUtilDate);

True with a decent-named "`toCfmlDateObject`" or something, no need for the comment. Good thinking.

just to clarify, a lucee date produced for example with the function “now” is a “java.util.Date” as well, because “lucee.runtime.type.dt.DateTimeImpl” extends “java.util.Date”. the difference is not that big. for example the method

toString

creates a different output (jdbc timestamp based on the timezone set in the lucee enviroment). lucee also can handle “java.util.Date”, no problem. “problem” is when you do

myDate.year()

you are not calling the year method, you are calling the build in member function year. i think the question is, what do you wanna achieve QM (question mark). but the difference between calling the method or the bif is the timezone used. the method simply uses the jvm default timezone and the bif the lucee env timezone, with the bif you can even define the timezone as argument explicitly. and yes all the date functions in lucee are using the

java.util.GregorianCalendar

for any date conversion. so using “java.util.Date” natively just has downsides in my opinion, because you will reinvent the wheel for many things. let me know what you wanna do an i can help you with that.

Oh cool. So there is perhaps nothing to address. My distillation from what you say is that I can treat an explicit

java.util.Date

as a native Lucee

date

type already. So any of the methods listed on https://docs.lucee.org/categories/datetime.html#methods can be called on a

java.util.Date

? Thanks - btw - for the very comprehensive answer!

yes you can use all the Date methods

Wow actually good to know... https://trycf.com/gist/6393d2fd77af98f727e0ed2f75890432/lucee5?theme=monokai

Thanks Micha.