Incorrect conversion of datetime string

dev support
1

When formatting / converting a datetime string with factional seconds the result is incorrect.

<cfscript>
data = [:];

data['source'] = '2022-07-25 20:40:15.352661';
data['local'] = dateFormat( data.source, "yyyy-mm-dd" ) & " " & timeFormat( data.source, "HH:mm:ss" );

dump( data );
</cfscript>

image

OS: Window & Linux
Java Version: Java 11.0.16
Servlet Version: Jetty 10.0.11
Lucee Version: Lucee 5.3.9.141

2

datetimeFormat() has issues too but they appear to be different. The minutes is always 07.

<cfscript>
data = [:];

data['source'] = '2022-07-25 20:40:15.352661';
data['local'] = dateFormat( data.source, "yyyy-mm-dd" ) & " " & timeFormat( data.source, "HH:mm:ss" );
data['dtformat'] = datetimeFormat( data.source, "yyyy-mm-dd HH:mm:ss" );

dump( data );
</cfscript>

image

3

Hey Andrew, the first seems clearly a bug.

On the second, there’s understandable confusion on that. datetimeFormat (in both Lucee and ACF) has different mask arguments than dateFormat and timeFormat, since it has to accommodate both kinds. As such:

m is for month, thus “always 7”, at least this month. :slight_smile:

n (or nn) is for minute

See the docs:

2 Likes
4

Adding to what @carehart already said, I’d also always parse any string representing a date/time to a datetime object first before doing anything with it. CFML really does lots of magic by parsing somehow any date string automatically, but it may have unexpected results then.

5

I’m going to test and compare before I comment… I used parseDateTime() as I thought it would be more accurate and discovered that more precision resulted in worse results. (ACF doesn’t seem to be affected.)

Cross-Platform CFML Syntax Used:

writeDump(parseDateTime('2022-07-25 20:40:15.352661'));

Lucee 5.LATEST (TryCF.com)

20:40:15.752    = 20:40:15
20:40:15.352    = 20:40:15
20:40:15.3526   = 20:40:18
20:40:15.35266  = 20:40:50
20:40:15.352661 = 20:46:07

Adobe 2016-20221

20:40:15.752    = 20:40:15
20:40:15.352    = 20:40:15
20:40:15.3526   = 20:40:15
20:40:15.35266  = 20:40:15
20:40:15.352661 = 20:40:15
1 Like
6

Thanks for the response. First one clearly a bug. The second one was a simple conversion mistake between timeFormat and datetimeFormat.

@Zackster - Is this a known bug?