Sql 在Informix中将DATETIME转换为Unix历元

我有一个DATETIME列：

从mytable中选择mytime

我想编写一条SQL语句，以Unix时间格式返回自Unix Epoch-01/01/1970 00:00:00以来的秒数，作为整数。我曾尝试使用DATEDIFF和CAST，但运气不佳。这是Informix数据库。

假设mytime列是DATETIME YEAR TO SECOND列（尽管问题中显示了格式），那么下面的存储过程将执行此任务。它的注释比程序多，但是注释解释了它在做什么

{
#   "@(#)$Id: tounixtime.spl,v 1.6 2002/09/25 18:10:48 jleffler Exp $"
#
# Stored procedure TO_UNIX_TIME written by Jonathan Leffler (previously
# jleffler@informix.com and now jleffler@us.ibm.com).  Includes fix for
# bug reported by Tsutomu Ogiwara <Tsutomu.Ogiwara@ctc-g.co.jp> 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;

---

函数dbinfo'utc_current'返回1970-01-01 00:00:00 utc以来的历元时间秒数。

mytime变量的类型是什么，因为这是一种显示结果的非标准格式，也是一种可怕的格式。它不能正常工作，昨天的价值比今天高。执行过程到unix时间'2020-05-14 10:50:10'5490414400执行过程到unix时间'2020-05-14 21:50:10'9450414400执行过程到unix时间'2020-05-15 10:50:10'5490500800执行过程到unix时间'2020-05-15 21:50:10'9450500800@Max-请给我发送电子邮件，查看我的个人资料。我无法复制您在MacBook Pro上运行的64位Informix 12.10.FC6和macOS 10.14.6 Mojave的结果。我得到了这四个调用的值：1589453410、1589493010、1589539810、1589579410，尽管每个调用在小数点后都有5个零。您正在使用哪个版本的Informix，运行在哪个平台上？您引用的值对应于2143年和2269年的时间，这令人费解。然而，这不能在评论中合理地讨论，添加到答案中会使其大小加倍，只会引起混乱。我的版本纪元9.50C1您如何推断版本是9.50C1？一种方法是使用informix.systables中的SELECT DBINFO'version'，'full'，其中tabid=1。原本是9.50版的版本被改为10.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
# jleffler@informix.com and now jleffler@us.ibm.com).  Includes fix for
# bug reported by Tsutomu Ogiwara <Tsutomu.Ogiwara@ctc-g.co.jp> 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;