Has anyone run into crashes calling isDate()? Here's a gist: https://trycf.com/gist/74820ddf24ba9a2bbf60da934a284a65/acf2021?theme=monokai That runs fine there on CF 2021 and 2023. Last four of those blow up on my dev site on 2021. Error for the first three that crash is "Date value passed to date function createDateTime is unspecified or invalid. Specify a valid date in createDateTime function" . Last one throws "HOUR_OF_DAY: 2 -> 3", which is, uh, odd. You'll notice that the code doesn't use createDateTime() at all, that's cf making that call. My java version is 11.0.20, trycf has 1.8.0_292 for those cf versions, which I mention because I don't know why else the behavior would be different with the same CF version. I thought we were supposed to be using 11.0.20. Thoughts?

I get the same results running CF 2021 and Java 11.0.22 locally.

@Rodney Thanks, interesting. Guess I should file a bug.

It fails with Java 8 as well.

Interesting, see the timezone where do you mean?

Add

setTimeZone("UTC")

at the top of your script.

Bingo, you're right, good call. Using setTimeZone("EST") works too, just needs to be something valid. Guess I need to figure out what time zone this app means to use, and how to request that.

It depends on the Java version in use.

Calling setTimeZone(getTimeZone().timezone) still crashes with the createDate error, which seems weird. That was my attempt at setting it without changing it. Also still crashes with setTimeZone("America/New_York"), which is the timezone I get from getTimeZone() if I don't set it at ll. Weird.

The code is a bit shite (ping @saghosh... opportunity to improve them here) , but they explain how to use the function, and the example shows how to get all the supported TZ codes. https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-functions/functions-e-g/gettimezone.html And this tweak of the example demonstrates they all "work": https://trycf.com/gist/85683551cff3b67dd1cfe314231303fc/acf2023?theme=monokai (will need to tweak a bit for Lucee as it's not cross-compat with CF).

I filed this bug: https://tracker.adobe.com/#/view/CF-4221137

Change the engine to Adobe. It defaults to Lucee 5.

Oh yeah right

@Dave Merrill your example missed the key info that it's USAn TZs that have the issue.

So what do folks think is the righteous workaround today, given that setTimeZone(getTimeZone().timezone) doesn't fix it? I don't want to hard code it, especially if it's daylight saving time sensitive.

I would always have servers set to UTC, and offset date/time output back to the "local" TZ for humans.

Use UTC at the OS level?

Am pretty sure Adobe already knows about this one. I can remember looking into it last time it came up

The is no 2am 0n 2024-03-10

Hah, funny that that's a value in question. However, with the setTimeZone() call in place, isDate("3/10/2024 2:00AM") returns true, and without it, various others crash too, so not the issue.

Ahem: https://trycf.com/gist/7ba2d604575fbb9697b6bd99c7100399/acf2021 It is the issue. If you set it to a TZ that isn't NY (or another TZ that doesn't switch to daylight saving at that moment), then - obviously - it won't be a problem. All this DLS shite is another reason to set servers to UTC.

You're right, it is the issue. Still begs the question of how to set it without changing it, and without adding weird exceptions to the code to handle those odd timezones. Seems that setting servers to UTC may be the only answer. I don't see an admin setting for this. Did I miss it? Or do I need to change the time on the server machine itself? All of this has Implications.

Or do I need to change the time on the server machine itself?

Yup

-Duser.timezone=UTC

in case you haven't figured it out @Dave Merrill At work, all our servers are configured to UTC at the O/S level. In addition, we specify that JVM property everywhere, even in dev (so tests have a consistent TZ to work in). We also explicitly configure our database to be UTC (everywhere, even in dev). And I believe we also have something in the DB connection string that ensures the server TZ is used consistently for all DB clients.

Making it UTC "everywhere" - just gets rid of so many problems. Then, the only place you ever need to worry about a TZ is where it is provided to an end user. • Displayed to a screen • Exported in a report / document • When collecting a date / time value in a form. ◦ Eg provide me a report from xx->yy ▪︎ you will need to convert from something to UTC • you can do this in code before the SQL • Most DB engines have a built-in function , too. • Scheduled tasks (that is someone says I want my custom report generated daily at 3am EST - you set the appropriate UTC time for 3am EST in the scheduled task section of you web admin / script. I am sure there are others, too - but it is only ever where it is "presented'

Agree about having an isDate() wrapper. Also agree that having CF and SQL servers running on UTC would avoid a lot of bogus workarounds, but a) We'd need to think through what should happen to existing db data when we turn that on. Seems like a huge set of updates. b) There are a lot of places in a lot of code where we'd need to adjust for end-user presentation, and buy-in for that work may not happen c) I'd be somewhat surprised if this wasn't considered in the long-ago past here, need to consult w some old-timers about that.

Oh yeah, my observation was "this is how it should have been from the outset", not "change it!!!". I think there's a good chance that particular ship has sailed for you; but - as you say - if you decided to undertake it... erm... good luck.

We are currently in your position. The server is in AEST (UTC+10) The DB is in AEST, too. Now we have to convert everything - everywhere, all the time for any customer that is not on eastern seaboard of Australia. And we don't make any allowances for Daylight Savings time - so too bad when crap runs 1 hour ahead of when you expect it! It is going to be a very significant amount of work to redress it. I am tempted to just live with it - but we have so many issues pop because code somewhere is using "LS<datetime-function> - and somewhere else isn't using the LS version. We have code in our SQL to deal with it - but is isn't always "seen" in the code - so you add TZ handling changes to your code - only to find you subtract another 10 hours - when it gets to the DB - and you spend days chasing your own ass around trying to work out what the hell is going on. The frustration and the wasted time makes me REALLY want to change it - but there are actual bugs that need priority and / or features promised - that need to be done before doing fixing something that "is" working. (poorly and at times hard to reason about - but working... and thus it is not the priority)

We're lucky in that AFAIK all our users are nominally on the East Coast of the US, so we're not doing any time localization. Switching the CF and SQL servers to UTC would require that we convert everywhere, UTC to local time for display, and local to UTC for storage. That last step may not always be necessary if we're just recording something that happened #now()#. However, if the user enters a date and/or time in the UI, which does happen, that'd be the user's local time, and would need to get converted to UTC. Updating all existing datetime data to convert it to UTC is also a scary project. Overall, a big mess.