Я искал способ сгруппировать данные по интервалу (например, каждые 30 минут), используя дату, определенную в этой таблице, поэтому мне нужно преобразовать эту дату в миллисекунды, чтобы я мог разделить ее на интервал, который мне нужен, как в этом запрос
SELECT FLOOR(UNIX_TIMESTAMP(timestamp)/(15 * 60 * 1000)) AS timekey
FROM table
GROUP BY timekey;
Этот запрос отлично работает на SQL Server, но на informix он дает мне ошибку
Routine (unix_timestamp) can not be resolved.
Поскольку он не определен на сервере IBM Informix.
Поэтому мне нужен прямой способ получить время unix эпохи из столбца timestamp
DATETIME YEAR TO FRACTION (3) на сервере IBM informix, например «UNIX_TIMESTAMP» на сервере SQL.
это DATETIME YEAR TO FRACTION(3) я отредактировал вопрос
Если столбец timestamp
имеет тип DATETIME YEAR TO SECOND или аналогичный, то вы можете преобразовать его в DECIMAL (18,5) число секунд, начиная с эпохи Unix, также известное как 1970-01-01 00:00:00Z (UTC; время смещение зоны +00:00), используя следующую процедуру:
{
# "@(#)$Id: tounixtime.spl,v 1.6 2002/09/25 18:10:48 jleffler Exp $"
#
# Stored procedure TO_UNIX_TIME written by Jonathan Leffler (previously
# [email protected] and now [email protected]). Includes fix for
# bug reported by Tsutomu Ogiwara <[email protected]> on
# 2001-07-13. Previous version used DATETIME(0) SECOND TO SECOND
# instead of DATETIME(0:0:0) HOUR TO SECOND, and when the calculation
# extended the shorter constant to DATETIME HOUR TO SECOND, it added the
# current hour and minute fields, as documented in the Informix Guide to
# SQL: Syntax manual under EXTEND in the section on 'Expression'.
# Amended 2002-08-23 to handle 'eternity' and annotated more thoroughly.
# Amended 2002-09-25 to handle fractional seconds, as companion to the
# new stored procedure FROM_UNIX_TIME().
#
# If you run this procedure with no arguments (use the default), you
# need to worry about the time zone the database server is using because
# the value of CURRENT is determined by that, and you need to compensate
# for it if you are using a different time zone.
#
# Note that this version works for dates after 2001-09-09 when the
# interval between 1970-01-01 00:00:00+00:00 and current exceeds the
# range of INTERVAL SECOND(9) TO SECOND. Returning DECIMAL(18,5) allows
# it to work for all valid datetime values including fractional seconds.
# In the UTC time zone, the 'Unix time' of 9999-12-31 23:59:59 is
# 253402300799 (12 digits); the equivalent for 0001-01-01 00:00:00 is
# -62135596800 (11 digits). Both these values are unrepresentable in
# 32-bit integers, of course, so most Unix systems won't handle this
# range, and the so-called 'Proleptic Gregorian Calendar' used to
# calculate the dates ignores locale-dependent details such as the loss
# of days that occurred during the switch between the Julian and
# Gregorian calendar, but those are minutiae that most people can ignore
# most of the time.
}
CREATE PROCEDURE to_unix_time(d DATETIME YEAR TO FRACTION(5)
DEFAULT CURRENT YEAR TO FRACTION(5))
RETURNING DECIMAL(18,5);
DEFINE n DECIMAL(18,5);
DEFINE i1 INTERVAL DAY(9) TO DAY;
DEFINE i2 INTERVAL SECOND(6) TO FRACTION(5);
DEFINE s1 CHAR(15);
DEFINE s2 CHAR(15);
LET i1 = EXTEND(d, YEAR TO DAY) - DATETIME(1970-01-01) YEAR TO DAY;
LET s1 = i1;
LET i2 = EXTEND(d, HOUR TO FRACTION(5)) -
DATETIME(00:00:00.00000) HOUR TO FRACTION(5);
LET s2 = i2;
LET n = s1 * (24 * 60 * 60) + s2;
RETURN n;
END PROCEDURE;
Некоторые комментарии об адресах электронной почты больше не действительны — за полтора десятилетия, прошедшие с тех пор, как я это написал, многое изменилось.
Я искал способ избежать использования хранимых процедур :'D
OK. Удачи. Я не думаю, что есть один.
Да, к сожалению, но спасибо, братан, это было потрясающе, может быть, я попробую.
Пожалуйста, дайте хотя бы соответствующую схему схемы таблицы. Является ли столбец
timestamp
столбцом DATETIME YEAR TO FRACTION(3), или столбцом DATETIME YEAR TO SECOND, или каким-либо другим типом (и если другого типа, то какого другого типа)? Временные метки Unix представляют собой целое число секунд, прошедших с «Эпохи» — также известное как 1907-01-01 00:00:00Z. Вам не нужно компенсировать с помощью «деления на 1000 для миллисекунд», если это действительно временная метка Unix, но есть части систем, таких как Java, которые используют «милли-временные метки» (например, временная метка Unix, но считается в миллисекундах, а не в секундах). ).