to the list
First of all, this errors are shown when I use the webservice client API,
When I tried to create a job using a datetime with timezone this is the
error log
File “/opt/zato/zato-1.1/zato-server/src/zato/server/scheduler.py”, line
96, in create_edit
handler(job_data, broker_msg_type)
File “/opt/zato/zato-1.1/zato-server/src/zato/server/scheduler.py”, line
107, in create_one_time
SCHEDULER_JOB_TYPE.ONE_TIME], name=job_data.name)
File
"/opt/zato/zato-1.1/eggs/APScheduler-2.0.3-py2.7.egg/apscheduler/scheduler.py",
line 300, in add_date_job
return self.add_job(trigger, func, args, kwargs, **options)
File
"/opt/zato/zato-1.1/eggs/APScheduler-2.0.3-py2.7.egg/apscheduler/scheduler.py",
line 274, in add_job
self._real_add_job(job, jobstore, True)
File
"/opt/zato/zato-1.1/eggs/APScheduler-2.0.3-py2.7.egg/apscheduler/scheduler.py",
line 230, in _real_add_job
job.compute_next_run_time(datetime.utcnow())
File
"/opt/zato/zato-1.1/eggs/APScheduler-2.0.3-py2.7.egg/apscheduler/job.py",
line 74, in compute_next_run_time
self.next_run_time = self.trigger.get_next_fire_time(now)
File
"/opt/zato/zato-1.1/eggs/APScheduler-2.0.3-py2.7.egg/apscheduler/triggers/simple.py",
line 9, in get_next_fire_time
if self.run_date >= start_date:
TypeError: can’t compare offset-naive and offset-aware datetimes
and after formating the datetime to “%Y-%m-%d %H:%M:%S” to obtain a normal
datetime without timezone, this is the error log
2014-05-30 23:02:47,928 - INFO - 11517:Dummy-9 -
zato.scheduler.job.create:22 -
cid:[K011397624108052907815571501002669803050],
name:[zato.scheduler.job.create], SIO r$
2014-05-30 23:02:47,945 - ERROR - 11516:Dummy-93 - zato.server.scheduler:22
- Caught exception [Traceback (most recent call last):
File “/opt/zato/zato-1.1/zato-server/src/zato/server/scheduler.py”, line
96, in create_edit
handler(job_data, broker_msg_type)
File “/opt/zato/zato-1.1/zato-server/src/zato/server/scheduler.py”, line
107, in create_one_time
SCHEDULER_JOB_TYPE.ONE_TIME], name=job_data.name)
File
"/opt/zato/zato-1.1/eggs/APScheduler-2.0.3-py2.7.egg/apscheduler/scheduler.py",
line 300, in add_date_job
return self.add_job(trigger, func, args, kwargs, **options)
File
"/opt/zato/zato-1.1/eggs/APScheduler-2.0.3-py2.7.egg/apscheduler/scheduler.py",
line 274, in add_job
self._real_add_job(job, jobstore, True)
File
"/opt/zato/zato-1.1/eggs/APScheduler-2.0.3-py2.7.egg/apscheduler/scheduler.py",
line 232, in _real_add_job
raise ValueError(‘Not adding job since it would never be run’)
ValueError: Not adding job since it would never be run
so I think that zato is passing my start_date to APScheduler as is, and
APScheduler is running his time without timezone, saying that my timezone
is UTC -5, APScheduler is running in localtime +5, I also check this
showing datetime.now() used to add the job in APScheduler and it confirm
that
On Sat, May 31, 2014 at 2:52 AM, Dariusz Suchojad dsuch@zato.io wrote:
On 05/31/2014 06:47 AM, Axel Mendoza Pupo wrote:
Basically APScheduller used by Zato is not timezone aware, affecting the
schedulling of task that have start_date bellow of the UTC time, for
example, for those servers who have their timezone datetime in UTC + 5
can’t schedule task that are bellow the range of now plus 5 hours, any
task
in that range of time is not getting scheduled by APScheduller because it
says that the task will never run.
That link says that this will be fixed in APScheduller 3.0, but until
then
what will be a possible solution in conjuntion with Zato??
Hi Axel,
APScheduler isn’t but Zato is, that’s the goal of these patches that get
applied when you install Zato binaries:
https://github.com/zatosource/zato/blob/master/code/patches/apscheduler/triggers/interval.py.diff
https://github.com/zatosource/zato/blob/master/code/patches/apscheduler/scheduler.py.diff
They make Zato servers always compute time of the next job’s run in UTC
rather than in local time.
Internally, all Zato’s own services operate in UTC only and that
includes the admin API.
Web-admin on the other hand always accepts input in user’s local timezone
…
https://zato.io/docs/web-admin/settings/main.html
… and it’s translated into UTC internally before a service to create a
job is invoked.
In other words, it’s UTC everywhere except for the user interface.
But if you say it isn’t, can you please post an excerpt from server.log
showing:
thanks a lot,
–
Dariusz Suchojad
https://zato.io
ESB, SOA, REST, APIs and cloud integrations in Python