Lubridate: force_tz() sollte Datumsangaben in Datums-Zeiten umwandeln

Ich denke, die letzten beiden sollten POSIX anstelle des Datums zurückgeben. Ich würde dies als Bug qualifizieren.

Finden Sie auch das erste Beispiel unerwartet? Dies ist eine Neuerung in der letzten Minor-Version, um nicht explizit mit den NULL-tzs umzugehen, aber ich bin nicht ganz davon überzeugt, dass es eine so gute Idee war.

Ich rate im Allgemeinen dringend davon ab, Daten in datetime hochzukonvertieren, und ich denke, dies implizit würde zu Problemen führen. Der typische Ansatz besteht darin, anzunehmen, dass die Zeit nur Nullen ist, aber dann kann with_tz das Datum leicht ändern, was meiner Meinung nach selten das gewünschte Ergebnis ist.

Ich hatte nicht daran gedacht, als ich dieses Problem erstellt habe, aber wenn ich darüber nachdenke, denke ich, dass das erste Ergebnis unerwartet ist, da ich ein Nicht-UTC-Gebietsschema festgelegt habe.

Wäre es sinnvoll, Zeitzonen von zeitfreien Date s ganz zu streichen? zB tz würde NULL oder with_tz / force_tz eine Warnung oder einen Fehler zurückgeben usw.

Mögliche Probleme könnten Randfälle wie der fehlende Tag in Samoa sein (https://zachholman.com/talk/utc-is-enough-for-everyone-right).

Sie fragen nach einer Operation, die bei Datum-Zeiten sinnvoll ist, die impliziert, dass Sie das Datum als einen Moment interpretieren. Warum sonst solltest du force_tz bei einem Date machen?

Wäre es sinnvoll, Zeitzonen von zeitfreien Dates ganz zu streichen?

Jawohl. Ich werde es auf NULL zurücksetzen.

Ich stimme zu, dass force_tz keinen Sinn ergibt; Ich habe es nur versucht, weil ich nicht das erwartete Verhalten von with_tz . Aus Gründen der Konsistenz bei einer Mischung aus Datums- und Uhrzeitangaben war es mein Ziel, die richtige Zeitzone _einzustellen_, und tz(x) <- "America/New_York" führt zu umständlichem Code. Nach dieser Diskussion möchte ich nicht einmal das tun; Ich denke, wir sind uns einig, dass Datumsangaben in keiner Weise Zeitzonen haben sollten.

Ich helfe gerne mit Code, habe aber erst morgen Zeit. Klingt so, als ob tz NULL ; was ist mit force_tz / with_tz ? Ein Fehler würde deutlich machen, dass lubridate keine Zeitzonen für Datumsangaben unterstützt, aber möglicherweise auch den Code des Benutzers brechen könnte. Könnte eine Warnung in einer Version und einen Fehler in einer nachfolgenden Version auslösen, wenn ein Bruch ein Problem darstellt, aber es ist möglich, dass niemand anderes versucht, Zeitzonen für ihre Daten festzulegen, wie ich es getan habe.

Es erscheint mir vernünftig, POSIXct zurückzugeben, wenn Sie explizit anfordern, dass eine Zeitzone zu einem Datum hinzugefügt wird. Das Hinzufügen eines tzone-Attributs zu einem Date-Objekt ist definitiv falsch:

library(lubridate, warn.conflicts = FALSE)

tz(force_tz(today(), "America/New_York"))
#> [1] "UTC"
class(force_tz(today(), "America/New_York"))
#> [1] "Date"

tz(with_tz(today(), "America/New_York"))
#> [1] "America/New_York"
class(with_tz(today(), "America/New_York"))
#> [1] "Date"

tz(`tz<-`(today(), "America/New_York"))
#> [1] "UTC"
class(`tz<-`(today(), "America/New_York"))
#> [1] "Date"

^{Erstellt am 20.11.2019 vom Reprex-Paket (v0.3.0)}

(Ich stimme zu, dass Lubridate Datumsangaben zu leicht in Datums-Zeiten umwandelt; aber das ist ein separates Thema)