The key points are that: a) Date values have no idea what timezone means. b) Sys.Date starts with local time and converts to Date, losing timezone info. c) You try comparing a Date with a POSIXt time value, and the conversion from Date to POSIXt _assumes UTC_. This is a problem for anyone not using UTC... regardless of whether you happen to be traveling or not.
The key is at the point where you try to mix them. As Ivan suggests, don't use Dates when using time values. Only use Date type when time is not relevant to your analysis. POSIXt is perfectly capable of representing Dates, the the reverse is not true. On June 28, 2024 10:16:20 AM PDT, Ivan Krylov via R-help <r-help@r-project.org> wrote: >В Fri, 28 Jun 2024 18:52:26 +0200 >Dennis Fisher <fis...@plessthan.com> пишет: > >> When I issue the command: >> Sys.Date() >> I would like to be able to obtain the value for Pacific time (which >> differ for the first 9 hours of the day) > >By the time the value of Sys.Date() is created, it's too late to >discern between Europe and Pacific time. The Date class is intended to >store the integer number of days since 1970-01-01: > >unclass(Sys.Date()) ># [1] 19902 > >Only by preserving the time we can get a timezone-dependent date: > >format(Sys.time(), '%Y-%m-%d') # uses the current time zone ># [1] "2024-06-28" >format(Sys.time(), '%Y-%m-%d', tz = 'Asia/Vladivostok') ># [1] "2024-06-29" > -- Sent from my phone. Please excuse my brevity. ______________________________________________ R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
