Início / coding / Perguntas / 79576099
Accepted
Nicole
Asked: 2025-04-16 06:13:24 +0800 CST

Estou recebendo um erro ao definir o fuso horário para a função R sunrise no pacote bioRad

  • 772

Tenho um dataframe de locais e datas nos EUA para o qual quero recuperar o horário do pôr do sol. Usei tz_lookup_coordso pacote lutz para definir o fuso horário com base na localização, mas quando insiro isso no bioRad, sunriserecebo uma mensagem de erro informando que o valor tz é inválido.

# create dataframe
data <- data.frame(id = 1:10,
                   date = c("2018-02-05", "2018-12-29", "2018-05-25", "2018-02-19", 
                            "2017-02-09", "2017-10-05", "2018-02-18",
                            "2017-11-27", "2017-10-13", "2018-12-03"),
                   wgs_x = c(-105.12782,  -73.70111, -119.89776, -157.94036,  
                             -85.62744,  -87.73867,  -90.03440 , -97.39539,
                             -112.34498,  -83.06242),
                   wgs_y = c(39.98948, 41.03264, 36.84011, 21.33720, 42.88368,
                             30.42648, 35.20090, 27.68490, 34.62111, 42.39886))
data$date <- as.Date(data$date)

# define timezones
data$timezone <- tz_lookup_coords(data$wgs_y, data$wgs_x, method = "accurate", warn = F)

# define sunrise time
data$sunrise <- sunrise(date = data$date, 
                        lon = data$wgs_x,
                        lat = data$wgs_y,
                        tz = data$timezone)

1 respostas

  1. Best Answer

    Sem saber o que você está vendo, tentarei reproduzir com base no que está sendo feito internamente bioRad::sunrise... ou seja, as.POSIXct(date, tz).

    data$timezone <- lutz::tz_lookup_coords(data$wgs_y, data$wgs_x, method = "accurate", warn = F)
data$timezone
#  [1] "America/Denver"      "America/New_York"    "America/Los_Angeles" "Pacific/Honolulu"    "America/Detroit"     "America/Chicago"     "America/Chicago"     "America/Chicago"     "America/Phoenix"     "America/Detroit"

    Até agora tudo bem. No entanto, com base em https://github.com/adokter/bioRad/blob/master/R/sunrise_sunset.R#L129 , vou tentar

    as.POSIXct(data$date, tz = data$timezone)
# Error in strptime(xx, f, tz = tz) : invalid 'tz' value

    (Para perguntas futuras, geralmente é muito esclarecedor incluir a mensagem de erro real. Nesse caso, ela teria apontado muito mais rápido para uma chamada para funções R base, como as.POSIXctou strptime, e não teria que se esforçar muito para encontrar outras causas possíveis.)

    O que não está bem documentado em?as.POSIXct

          tz: a character string.  The time zone specification to be used
          for the conversion, _if one is required_.  System-specific
          (see time zones), but ‘""’ is the current time zone, and
          ‘"GMT"’ is UTC (Universal Time, Coordinated).  Invalid values
          are most commonly treated as UTC, on some platforms with a
          warning.

    é que tz=deve ter comprimento 1. Isso ocorre porque um vetor de POSIXtvalores em R deve ter o mesmo fuso horário. Ou seja, não é possível ter dois timestamps em um vetor com fusos horários diferentes; o "tzone"atributo é aplicado ao vetor como um todo. (Uma coluna de um quadro é apenas um vetor.)

    Para ajudar a provar este ponto,

    as.POSIXct(data$date, tz = data$timezone[1])
#  [1] "2018-02-05 MST" "2018-12-29 MST" "2018-05-25 MDT" "2018-02-19 MST" "2017-02-09 MST" "2017-10-05 MDT" "2018-02-18 MST" "2017-11-27 MST" "2017-10-13 MDT" "2018-12-03 MST"

    Porém, dependendo dos seus dados, isso pode alterar alguns valores de tempo.

    Outra abordagem seria converter cada um de acordo com seus fusos horários específicos e, em seguida, combiná-los. Uma primeira tentativa poderia usar mapply, mas isso tende a remover a classe:

    mapply(as.POSIXct, data$date, tz = data$timezone)
# 2018-02-05 2018-12-29 2018-05-25 2018-02-19 2017-02-09 2017-10-05 2018-02-18 2017-11-27 2017-10-13 2018-12-03 
# 1517814000 1546059600 1527231600 1519034400 1486616400 1507179600 1518933600 1511762400 1507878000 1543813200

    Podemos consertar isso usando Mape do.call(c, ..):

    do.call(c, Map(as.POSIXct, data$date, tz = data$timezone))
#                2018-02-05                2018-12-29                2018-05-25                2018-02-19                2017-02-09                2017-10-05                2018-02-18                2017-11-27                2017-10-13 
# "2018-02-05 00:00:00 MST" "2018-12-28 22:00:00 MST" "2018-05-25 01:00:00 MDT" "2018-02-19 03:00:00 MST" "2017-02-08 22:00:00 MST" "2017-10-04 23:00:00 MDT" "2018-02-17 23:00:00 MST" "2017-11-26 23:00:00 MST" "2017-10-13 01:00:00 MDT" 
#                2018-12-03 
# "2018-12-02 22:00:00 MST"

    Observe que o R tende a considerar datas como UTC, e a conversão para carimbos de data/hora baseados em fuso horário produz horários diferentes. Como, como mencionei anteriormente, todos os valores POSIXt em um vetor devem compartilhar o mesmo fuso horário, todos eles são convertidos para o horário do primeiro fuso horário, embora você possa ver claramente que o horário é diferente para cada um.

    Dito isso... todos eles apontam para a mesma data UTC convertida em um horário. Se você converter cada um desses carimbos de data/hora de MDT para o fuso horário retornado por tz_lookup_coords, eles retornarão à meia-noite:

    
do.call(c, Map(as.POSIXct, data$date, tz = data$timezone)) |>
  Map(f = function(tm, tz) `attr<-`(tm, "tzone", tz), data$timezone)
# $`2018-02-05`
# [1] "2018-02-05 MST"
# $`2018-12-29`
# [1] "2018-12-29 EST"
# $`2018-05-25`
# [1] "2018-05-25 PDT"
# $`2018-02-19`
# [1] "2018-02-19 HST"
# $`2017-02-09`
# [1] "2017-02-09 EST"
# $`2017-10-05`
# [1] "2017-10-05 CDT"
# $`2018-02-18`
# [1] "2018-02-18 CST"
# $`2017-11-27`
# [1] "2017-11-27 CST"
# $`2017-10-13`
# [1] "2017-10-13 MST"
# $`2018-12-03`
# [1] "2018-12-03 EST"
    • 2

relate perguntas