You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

crypto2包数据返回的起始日期与时区异常问题排查

crypto2包日期筛选与时区问题解析及解决办法

一、数据点缺失(仅4个而非预期5个)的原因与解决

问题本质:Date与POSIXct的时区隐式转换偏差

  • Sys.Date()-5返回Date类型(仅日期,无时区属性,对应本地时区当日午夜)
  • 加密货币数据的timestamp是POSIXct类型(带时区的时间戳)
  • 当用Date类型的start_date传入crypto_history()时,函数内部将其转成UNIX时间戳的过程中,R默认采用本地时区(IST):
    • 你的Sys.Date()-5是2024-01-31,转成IST时区的POSIXct为2024-01-31 00:00:00 IST
    • API返回的2024-01-31 23:59:59 IST对应UTC时间是2024-01-31 18:29:59,早于IST时区的2024-01-31 00:00:00(IST比UTC快5.5小时),因此这条数据被筛选排除,最终少一个数据点。

解决办法

将start_date显式转换为UTC时区的POSIXct类型,确保与API的UTC时间逻辑对齐:

# 生成UTC时区的起始日期,包含目标日期的全量UTC数据
start_date_utc <- as.POSIXct(Sys.Date()-5, tz = "UTC")
coin_hist_5_days <- crypto_history(coins, start_date = start_date_utc)

二、时区显示为IST而非UTC的原因与解决

问题本质:函数未指定时区参数导致本地时区隐式转换

crypto_history()源码中,将日期转成UNIX时间戳时未指定tz参数:

# 源码存在的问题(未指定时区)
UNIXstart <- as.numeric(as.POSIXct(start_date))

当start_date为Date类型时,as.POSIXct()默认用本地时区(IST)转换,返回的timestamp也会以本地时区格式展示,而非API实际返回的UTC时间。

解决办法

方法1:修正已有数据的时区

直接将获取到的timestamp转换为UTC时区显示:

coin_hist_5_days$timestamp <- as.POSIXct(coin_hist_5_days$timestamp, tz = "UTC")

方法2:调用函数时传入UTC时区起始日期

同第一个问题的解决逻辑,从源头避免时区偏差:

start_date_utc <- as.POSIXct(Sys.Date()-5, tz = "UTC")
coin_hist_5_days <- crypto_history(coins, start_date = start_date_utc)

方法3:修改函数源码(可选)

若你有权限修改包源码,可在crypto_history.R中给as.POSIXct()添加tz="UTC"参数:

UNIXstart <- as.numeric(as.POSIXct(start_date, tz = "UTC"))
UNIXend <- as.numeric(as.POSIXct(end_date, tz = "UTC"))

内容的提问来源于stack exchange,提问作者user2338823

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.06.30 16:40:29