Yes, sort of an odd use case, but I understand it now. I’ve made a change which is a bare minimum to allow your exact use case to work, but not much else.

• The Plus operator specifically has been modified to allow specific existing date classes to be cast to a number

• This does NOT attempt to cast strings and such to numbers-- it will just use existing actual date instances

• The number is Java’s epoch milliseconds, NOT CF’s custom decimal days since December 30, 1899

What will NOT work is

• Code that specifically expects CF’s epoch number value. This really makes zero sense for BoxLang to adopt, but perhaps the compat module could offer this if needed

• ANY other usage of a date as a number outside of the Plus operator. The compat module could offer this if needed in the future, but performance and unexpected behavior is a concern here.

• Any ability to cast a number back to a date. The compat module could offer this if needed in the future, but performance and unexpected behavior is a concern here.

I guess we didn’t use randRange() as it was buggy with large numbers in Lucee and older ACF versions.
See links in this doc: https://cfdocs.org/randrange
See https://trycf.com/gist/726e96e5c5e9498b32a2/acf2016 - still issues in Lucee 5 and 6, but works in Boxlang

@Brad Wood We often have cases where we want so set a unique id for a form or div. e.g.

Not sure why we didn’t use createUUID, I guess we wanted only numbers and no characters or -

The one use case that I do think is handy is being able to add days to a number. Like now() + 1 is exactly 1 day from now. This is something even SQL Server allows you to do, which I’ve used a lot.

However, I also don’t care much for the ambiguity of “all dates are numbers” and “all numbers are dates”. While it works in a couple places, it doesn’t necessarily make sense for all numeric member methods to work on dates and all date member methods to work on numbers. That can cause a plethora of unexpected behaviors and adds performance overhead to our casters, all for a scenario only used 1% of the time.

@Harry Klein Can you help us understand the real life code making use of this behavior so we can better understand a solution that would satisfy your needs without adding full interoperability between numbers and dates?

I would hate to see us get murkier on our types on this one - especially since the numeric casting that Lucee and ACF performs is an epoch value that is no longer standard https://en.m.wikipedia.org/wiki/Epoch_(computing) (see “notable epochs”)

If we do this I really think it should only be for compat - like we are doing with booleans