Is the "in the future" calculation correct?

[ralsina]

What we are doing now is: we are comparing the post's date (with the TZ expressed in the date or in conf.py) against the current naive datetime with the TZ from conf.py applied.

I suspect it would make more sense to use a non-naive now() with the system's current TZ?

[Kwpolska]

the system's current TZ

We don’t know that. And we don’t need to, as having an aware post date and an aware now(UTC) is enough (as the timezone magic will take care of that)

[ralsina]

Yes we do know it, dateutil.tz.tzlocal() gives you the current TZ

[Kwpolska]

Sorry, I’m not well-versed in dateutil, and did not know this. Sure thing — it does get the current TZ, from time.(time|alt)zone, and also handles DST well enough.

But still, we don’t really need the current timezone for this.

[ralsina]

If we use the conf.py TZ then move east, you will create every new post in the future, because it will combine the naive "now" with the conf.py TZ :-)

[Kwpolska]

So let’s not do naïve: let’s do UTC, and then it will combine aware UTC now and aware TZ — which will take care of itself.

Besides, one cannot compare aware and naïve date-times.

[ralsina]

We are not comparing naive datetimes with non-naive ones, we are taking a naive one taken from the system clock, and blindly assigning a TZ that's not the system clock's to it. I'll propose a branch to "do the right thing".