Optimized: Date-Time conversion and processing

[dvdvideo1234]

No description provided.

[robotboy655]

This actually just completely breaks backwards compatibility - not only the format is not the same, the input value is interpreted differently in the new version.

I am also not sure we need more of the aliases for os.date with util.Date and util.Time.

[dvdvideo1234]

Hello,

This is because DateStamp does not use the second argument to be converted, and the DateStamp2 does:

local tst = 1337 ; util = {}

function util.DateStamp()
	local t = os.date( '*t' ) -- No second argument to be converted
	return t.year .. "-" .. t.month .. "-" .. t.day .. " " .. ( "%02i-%02i-%02i"):format( t.hour, t.min, t.sec )
end
function util.DateStamp2( vS )
	return os.date( "%Y-%m-%d %H:%M:%S", vS )
end
print(util.DateStamp(tst), util.DateStamp2(tst))

If the users desires the current date and not some other specific date to be converted they can pass nil as the second argument to make this behavior happen. Keep in mind that DateStamp does not have argument and this value will be always nil for it:

print(util.DateStamp(nil), util.DateStamp2(nil))
2023-11-1 19-19-35	2023-11-01 19:19:35

The function can be optimized to internally use os.date and avoid making structures, do concatenations and formatting that os.date does internally thus significantly improving performance

[robotboy655]

Fair enough, I have missed that the original had no arguments. Still, I do not think we need those other 2 functions, and I am still not sure about the formatting change.

[dvdvideo1234]

Well, time format is standardized across the world for using HH24:MI:SS ( not talking about AM/PM being less common ) and the date format is not just a random preference and you can use this format also to compare dates as strings. You can either convert SYSDATE or some other date you give it as argument. As an Oracle DB Developer I use date formatting every day and sure they have a lot... Generally yyyy-mm-dd hh24:mi:ss is used as a standard universal format for internal calculations and storage which eases date usage across other dependent platforms.

There is no harm in having the other two functions I think as the more, the merrier... They will be useful when the user requests only the date or the time part of SYSDATE and will receive it formatted nicely. Later it is even easier to extract and convert every part you want as minutes, seconds, days, month and so on just by using patterns. I think the game will benefit from it really good.

[robotboy655]

The point is not what format is common or what your preference is, the point is what it already is before your changes. Changing it can have adverse effects on existing scripts who may or may not expect a specific format. These issues happen time and time again with these PRs and with other changes to existing API functions.

On the topic of the 2 extra functions, they are just an alias of os.date. I see no point in adding them. People can use os.date like they always have.

[dvdvideo1234]

Adding DateStamp it again feels like an alias of os.date. My personal fix for this issue is just to use os.date. My only problem with this is that is slow, non-robust and also feels a bit redundant resulting in non-standard format nonetheless ;)

[dvdvideo1234]

Fair enough :D