Setting date labels loses tz

[hadley]

library(ggplot2)

df <- data.frame(
  time = as.POSIXct(as.Date("2010-01-01"), tz = "America/Chicago") + 1:10 * 3600,
  y = 1:10  
)

ggplot(df, aes(time, y)) + geom_point()
ggplot(df, aes(time, y)) + geom_point() + scale_x_datetime(date_labels = "%H:%M")

[bogdanstate]

In your example, there seems to be an issue with the timezone not being properly inherited from the Date object when using as.POSIXct. E.g.:

> attr(as.POSIXct(as.Date("2010-01-01"), tz="America/Chicago"), "tzone")
NULL
> attr(as.POSIXct("2010-01-01", tz="America/Chicago"), "tzone")
[1] "America/Chicago"

I can still reproduce the issue with the timezone reverting to UTC with the following example:

library(ggplot2)
library(gridExtra)

df <- data.frame(
  time = as.POSIXct("2010-01-01", tz = "America/Chicago") + 1:10 * 3600,
  y = 1:10  
)

p1 <- ggplot(df, aes(time, y)) + geom_point()
p2 <- ggplot(df, aes(time, y)) + geom_point() + scale_x_datetime(date_labels = "%H:%M %Z")
grid.arrange(p1, p2)

The issue seems to be related to a call to scales::date_format not inheriting the time zone.

[hadley]

@thomasp85 I think you'll need to take a look at this one. I did a bit of exploration, and the basic problem is that the scale only gets the date time variables once they've been transformed to numeric, so the tzone attribute has been lost.

I think this implies that ScaleContinuousDatetime needs a fairly heavy rewrite. It's currently a thin wrapper around ScaleContinuous, but it is probably actually sufficiently different that it should be it's own beast - it doesn't really need a transform argument, the breaks and labels are specified differently, and the train() method needs to remember first non-NULL tzone attribute

The scale also needs a way to optionally override the tzone used by the data.

[thomasp85]

My god, date/time scales is a mess... :-)

[thomasp85]

Doesn't it make sense to still inherit from ScaleContinuous, but overwrite more than just the map() method?

It seems that despite the differences there is still a lot of overlaps

[hadley]

Possibly, but it needs a lot of overriding, and at a certain point it's just easier to not inherit behaviour (or pull out duplicated behaviour into other functions/smaller classes, i.e. composition over inheritance)

[thomasp85]

Is it unthinkable that people for some reason would want to transform a timeseries?

[hadley]

I don't think I've ever seen a custom transformation in the wild, and I think you'd need that currently to (e.g) log transform a time axis. That said, I can imagine a transformation that (e.g.) dropped weekends, but I'm not sure if ggplot2 can handle non-one-to-one transforms.

[thomasp85]

Couldn't this be solved using the train_complete() addition proposed in #1708, rather than a complete rewrite?

[hadley]

Oh yes, that's quite possible. If you make that change, I'll take a look at this code.