I don't think you need to use EXTEND
in this context - EXTEND
is used to change the scale of DATETIME and INTERVAL values.
UTC_TO_DATETIME
returns a DATETIME value already.
Have you tried:
SELECT user_id, dbinfo("UTC_TO_DATETIME",min(creationdate)) AS earned_date
FROM message
What does that produce?
UPDATE
Ahh, an example makes all the difference!
The value you are passing is not a UTC datetime as UTC_TO_DATETIME
expects. The function expects an integer representing seconds, not milliseconds. It's as simple as that.
DBINFO('UTC_TO_DATETIME', 1329994172574)
exceeds integer precision.
DBINFO('UTC_TO_DATETIME', 1329994172574/1000)
on the other hand, produces:
2012-02-23 21:49:32
, which I guess is what you expect?
If you have a look at the link I provided earlier, it explains treatment of fractional seconds. (Spoiler: they're ignored.)
If the fractional seconds are critically important, I guess you're going to have to EXTEND
the results of this function to fractional seconds, and then add MOD(creationdate,1000)/1000 to it.
For example:
SELECT user_id,
(dbinfo("UTC_TO_DATETIME", MIN(creationdate)/1000 )::DATETIME YEAR TO FRACTION(3)
+ (MOD(MIN(creationdate),1000)/1000) UNITS FRACTION) AS earned_date
FROM message
(But personally, I would be inclined to put this logic into an SPL anyway, so you could call it like:
SELECT user_id, millis_to_time(MIN(creationdate))...
and avoid writing this sort of complex algorithm all over the place.)