I am not sure what this has to do with timezones embedded in specific POSIXt
vectors? Can you elaborate why this is relevant?
On October 10, 2024 11:32:31 AM PDT, Gabor Grothendieck
wrote:
>Sys.setenv(TZ = "GMT") will set the local time zone to GMT so there
>would only be one time
>zone regardl
Sys.setenv(TZ = "GMT") will set the local time zone to GMT so there
would only be one time
zone regardless of whether local or GMT were used.
On Thu, Oct 10, 2024 at 11:17 AM Jan van der Laan wrote:
>
> Thanks.
>
> On 10/10/24 16:13, Jeff Newmiller wrote:
> > POSIXt vectors do not support differe
Thanks.
On 10/10/24 16:13, Jeff Newmiller wrote:
POSIXt vectors do not support different time zones element-to-element.
> I complained about this on this list a couple of decades ago, and was
chastised for it. Evidently handling timezones per element was
considered to be too impractically s
POSIXt vectors do not support different time zones element-to-element.
If you want to keep track of timezones per element, you have to create a vector
of timestamps (I would recommend POSIXct using UTC) and a parallel vector of
timezone strings. How you manipulate these depends on your use cases
It is not completely clear to me how time zones work with POSIXlt
objects. For POSIXct, I can understand what happens: time is always
stored in GMT, the `tzone` attribute only affects how the times are
displayed. All computations etc. are done in GMT.
POSIXlt objects have both a `tzone` att
Dear Thomas,
Unfortunately, I do not know if any packages implement this functionality.
Though, it is a topic that interests me.
Unlike the "classic discriminant", I prefer to work with the reduced
polynomial. This "discriminant" is generalizable to a superset of Chebysev
polynomials (which I
6 matches
Mail list logo
