Idea: utcnow() or now('utc'), and today() or today('utc') functions

language
#1

Just wondering what people use for now() for utc datetimes. Could we tweak now to have a utc attribute, or create a new function utcnow (as several db’s use).

We store all dates/times in utc (so there is never confusion) so wondering if this would be useful, or there is a better way.

Would be great to have the today() function (today’s date with 12am as the time) and utcnow() (utc datetime right now) in the lucee toolkit, these are in python, and used across dot net and sql server and several other languages.

Could be a good inclusion for 6.x series - not sure why ColdFusion 2021 missed these also.

What do people think about this?

3 Likes
#2

Nice one,
I’ve filed an enhancement ticket for this https://luceeserver.atlassian.net/browse/LDEV-3206

2 Likes
#3

I like this idea. You can set the timezone for your Lucee server, but if you only want some code to get the current date in a given timezone, this would be handy. I just needed to do some time zone conversions recently, and while all the information is there, it’s a bit more manual then I would have preferred.

#4

We actually have a utcNow() UDF at work. I think it’s really just doing this under the hood:

dateConvert( "local2utc", now() )

We also have one called dateStripTime( date ), which creates a date with a 12am time:

function dateStripTime( required date input ) {

	return( dateSetTime( input, 0, 0, 0 ) );

}

function dateSetTime(
	required date input,
	required numeric newHours,
	required numeric newMinutes,
	required numeric newSeconds
	) {

	return(
		createDateTime(
			input.year(),
			input.month(),
			input.day(),
			newHours,
			newMinutes,
			newSeconds
		)
	);

}

It would be great to have things like this built in.

#5

yeah and support for JS date format

https://luceeserver.atlassian.net/browse/LDEV-2131

#6

Recently, while discovering some of Lucees videos, I’ve seen Micha telling to avoid that dateConvert() function. You can see his explanation/point of view here in this video

1 Like
#7

I appreciate Micha’s point about the date/time and the timezone; but, I think he’s being a little “abstract” in his reasoning. At the end of the day, we (developers) normalize dates into UTC before we store them. In his example, he’s calling dateConvert() like 12-times on the same date value, which is decidedly not “normalizing” the date. I wouldn’t expect that to result in a meaningful value. However, calling dateConvert() once to make sure the value is normalized, I would expect that to work and I use it all the time to make sure that the server clocks aren’t in any messed-up setting.

I actually keep my local development environment clock set to EST - rather than UTC - so that I can make sure that my times are being normalized properly. If I see EST dates showing up in my local database, I know that I am mishandling a date somewhere, forgetting to normalize it properly.

#8

So true, Ben. I also think Micha has his point, but at the end of the day we developers need to make things work with the tools/functions we have just like you do. I’ve used dateConvert() also ( that by the way was introduced to me by one of your blog posts… Please, always keep your blog alive!!! ). Now, thanks to Micha, I have more background information about all datetime stuff that will popup into my mind whenever I use dateConvert().