timezone problem

[idlesysman]

my db‘s timezone

db=# show timezone ; TimeZone

PRC (1 row)

when i insert some record to cron.job,find that exection time is not the db‘s default timezone(RPC). it seems that using UTC.

[marcocitus]

Like cron, pg_cron always uses GMT. Would adding a timezone GUC help?

[dumbuzz]

Cron runs in the local time. Could you please make conversion to GTM in pg_cron a configurable option?

[mccuskk]

Just been bitten by this as well. Wouldn't it make more sense for pg_cron times to be the same as reported in localtime? Failing that perhaps it would be better to state the timezone when adding a new cron job so you would have:

SELECT cron.schedule(schedule, command, timezone);

Where timezone would be the pg_timezone_names.abbrev e.g. 'BST'. This would be handy as some pg_cron jobs we run are local time dependent e.g. run at 9:00AM local time but I can imagine a mix in a more geographically distributed environment.

[ArcadeRenegade]

A way to configure the library to use a specific timezone would be really useful.

Especially if you are in a timezone that has daylight savings, like PST. Otherwise, we have to change the schedule of our jobs every time daylight savings changes.

Thanks.

[3kkani]

We have the same issue. Using localtime would be ok to avoid changes for daylight savings but specify the timezone for each job seems much better as it should cover anything you might need. Any forecast about when a fix could be implemented?

[suishaojian]

Any progress about this problem ?

[elkejava]

Is there any possibility to configure pg_cron to use local time meanwhile? Also for my use case this would be great.

[Schlumie]

Would also need local timezone. Every tine Sommer/Winter time changes, jobs are shifted 1 hour...

[gnudiff]

Would also need local timezone. Every tine Sommer/Winter time changes, jobs are shifted 1 hour...

I second that.

While it may be beneficial for Postgres server to convert or assume all dates UTC internally, it doesn't work for cron, or for anything really.

Consider SELECT cron.schedule('59 '|| date_part('hour',now()) || ' * * *','SELECT 1') . You'd expect it to run at 59th minute of current hour, but it will actually do so ONLY if you happen to be at UTC.

[cesarjorgemartinez]

The logic is use local time zone, the configured in show timezone in postgresql.

[OJFord]

Having a timzone (or using system) sounds good, but adjusting for summer time is a can of worms - what about jobs scheduled for say 0130, do you want them not to happen at all the day the clocks go forward, and twice on the day they go back? Wouldn't be worth it even if possible/simple to implement IMO.

[Schlumie]

This problem isn't new? Normally the last execute time is stored per job to help determine if job already run or didn't run/was skipped due to summer/wintertime change.

[hslightdb]

our fork https://github.com/hslightdb/pg_cron is tz-aware. in pg_cron--1.4-1--1.5.sql

[sv-hmelevsky]

The problem is still there! :( I use Postgresql 10. pg_cron was builded from repo clone. pg_crone ext version 1.4-1. Inside DB i set +3 GTM, in OS i set local timzeone to +3GMT. Then I restarted db, cron, rsyslog. Rescheduled all my cron.job. But pg_cron still start job at UTC

[marcocitus]

#219 added a cron.timezone, which currently defaults to GMT for backwards compatibility