isdate(Jun 17, 2025) returns false even though locale is set to " en-US"
DateFormat(“Jun 17, 2025”, ‘mmm d, yyyy’) returns
Can’t cast String [Jun 17, 2025] to a value of type [datetime]
I thought that i remembered having a similar issue when going from lucee 5 to 6.
The only way to get around this is use now is by using parseDateTime().
If this is not fixed it is going to require an unbelievable amount of code changes and testing for us.
Please always state exact versions when reporting bugs, I am assuming you mean the latest stable 6.2?
BTW, as 6 is LTS, I’d be going straight to 7.0 myself, otherwise you’re just battling tech debt ( LTS means maintenance mode ) and missing out on all the new stuff, modern extensions, native step debugger and the easy upgrade path to the faster 7.1 coming up soon
and if you are using ORM, this should really make your life easier
Sorry about that.
Lucee 7.0.3.43
Loader Version 7.0.1.100
Servlet Container Apache Tomcat/11.0.15
Java 24.0.2 (Eclipse Adoptium) 64bit
OS Windows Server 2022 (10.0) 64bit
Architecture 64bit
Looks like Jira is back.
ok, and you’re saying this differs from Lucee 6?
which version did it work on previously?
Could be java 24 related, try with 21?
Lucee depends on java for most date handling, so there are complications
but can you that trycf sample i shared and report back?
It is currently working in Lucee 6.2.4.24 and 21.0.5 (Eclipse Adoptium) 64bit .
It appears that it a problem with 6 and was fixed in 6.2.1.51. Jira
I may have incorrectly assumed that it may be the same issue that somehow came back.
We are using java 25 for migration testing as it states here that it has the best performance with Lucee7. Lucee 7 new features :: Lucee Documentation
I will give 21 a try.
Looks like Java 21 works as expected.
<cfdump var="#isdate('May 12, 2026')#"/> returns true.
Does this mean our code base is forever stuck on 21?
Stick with LTS versions. I usually look at the Docker files and use their versions unless there has been security updates since then.
Java 25 worked fine also on my 7.1 test site.
You tested <cfdump var="#isdate('May 12, 2026')#"/> on java 25 and lucee 7.1?
I did the Jun 17 one.
I just tried what you typed and it also worked.
Personally, I think Java 25 is fine, 21 is the baseline,
I am yet to be convinced there is actually a reproduceable problem here, something else is in play?
Like any issue, once we have an actual reliable repo, of course fix it
Most of the date pain was between java 11 and 21
Quick sanity check on the literal in your code:
<cfset s = "Jun 17, 2025">
<cfoutput>#toBase64( s.getBytes( "UTF-8" ) )#</cfoutput>
Should print SnVuIDE3LCAyMDI1.
<cfset s = "Jun 17, 2025">
#toBase64( s.getBytes( “UTF-8” ) )#
does return SnVuIDE3LCAyMDI1.
but <cfdump var="#isdate(s)#"/> returns false
I currently have a simple cfm page with
<cfset s = "Jun 17, 2025">
<cfoutput>#toBase64( s.getBytes( "UTF-8" ) )#</cfoutput>
<cfdump var="#isdate(s)#"/>
@KabutoTX1 are you saying that you are getting a different result running on
Apache Tomcat/11.0.15
24.0.2 (Eclipse Adoptium) 64bit
Lucee 7.0.2.106
?
Point of truth is the latest always the latest snapshot aka HEAD, older versions won’t might contain tech debt
I shared a trycf example, you didn’t really reply to it? Other people are also unable to reproduce the problem you’re citing
Trycf is on an very older beta still
I’m not saying there’s not a problem, but you haven’t provided a repo yet? Perhaps there’s something in your code or environment causing the problem
The link you posted above throws an error. Is there something there that I am supposed to run on my install? TryCF.com
I was able to use the scratch pad and set it up to use 7.1 and java25 and got
component {
this.name = "SimpleApp_" & hash(getCurrentTemplatePath()); // Unique name
this.applicationTimeout = createTimeSpan( 0, 2, 0, 0 ); // 2 hours
this.sessionManagement = true;
this.sessionTimeout = createTimeSpan( 0, 0, 20, 0 ); // 20 minutes
public boolean function onApplicationStart() {
application.startupTime = now();
return true;
}
public boolean function onSessionStart() {
session.started = now();
return true;
}
public boolean function onRequestStart( string targetPage ) {
if ( structKeyExists( url, "reinit" ) ) {
onApplicationStart();
info = {
"Lucee Version": server.lucee.version,
"Tomcat Version": getPageContext().getServletContext().getServerInfo(),
"Java Version": createObject("java", "java.lang.System").getProperty("java.version"),
};
writedump(info)
var = {};
var.today = DateFormat(now(), "mmmm d, yyyy");
var.isDate = isdate(var.today);
writedump(var)
cfabort()
}
return true;
}
}
I get
I also tried:
Lucee 7.0.3.43, java 24.0.2 (Eclipse Adoptium) 64bit, Apache Tomcat/11.0.15
Lucee 7.0.3.43, 25.0.3 (Eclipse Adoptium) 64bit , Apache Tomcat/11.0.15
Lucee 7.1.0.71-BETA, 25.0.3 (Eclipse Adoptium) 64bit , Apache Tomcat/11.0.15
var.today = DateFormat(now(), "mmmm d, yyyy");
var.isDate = isdate(var.today)
returns false in each case
I also tried I also tried Lucee 7.1.0.115-SNAPSHOT, 25.0.3 (Eclipse Adoptium) 64bit, Apache Tomcat/11.0.21 which matches the cftry example exactly and still get false for is date.
What could this be? I cleared all the class files between each version change still getting same results.
Works fine if I downgrade Java to 21.0.11 (Eclipse Adoptium) 64bit but keeping Lucee 7.1.0.71-BETA, Apache Tomcat/11.0.21
Finally figured it out. When we migrated from Java 9 to 21 we had added the following to our JVMoptions -Djava.locale.providers=COMPAT,HOST,CLDR;. Apparently Java 22 and up not longer has COMPAT as an option. Removing ‘COMPAT’ fixed the issue. You would think JAVA would just ignore it but it does not and breaks that specific date format.
I removed:
-Djava.locale.providers=COMPAT,HOST,CLDR
and added:
-Duser.language=en;
-Duser.country=US;
-Duser.timezone=America/Los_Angeles;
appears to work.
Glad you managed to figure it out, thanks for sharing the finding
the JVM args were a missing gap, but I couldn’t seem to repo the problem, even with them set
did see a jvm warning tho Invalid locale provider adapter "COMPAT" ignored.
java 9 eh, is this a very old Lucee install?
We updated from 5x to 6x when 6x first came out. We most likely updated Java at the same time. For some reason we felt the need to add -Djava.locale.providers=COMPAT,HOST,CLDR at the time. Not sure why now but I would think we were seeing some date formatting issues.