logstash[840964]: } 11402 .
```
When I look my record of generated JDBC timestamps that Logstash creates, I see:
```auto
[Date / Time Created] --- !ruby/object:DateTime 'GENERATED TIMESTAMP'
2021-07-15 02:23:01 --- !ruby/object:DateTime '2021-07-15 00:21:54.000000000 Z'
2021-07-15 02:24:01 --- !ruby/object:DateTime '2021-07-15 00:22:56.000000000 Z'
2021-07-15 02:25:01 --- !ruby/object:DateTime '2021-07-15 00:22:56.000000000 Z'
2021-07-15 02:26:01 --- !ruby/object:DateTime '2021-07-15 00:22:56.000000000 Z'
...
2021-07-15 16:32:01 --- !ruby/object:DateTime '2021-07-15 00:22:56.000000000 Z'
```
Where --- !ruby/object:DateTime 'GENERATED TIMESTAMP' is contained within "/path/to/.logstash\_jdbc\_update".
So in the same pipeline cycle the scheduler throws this error, the pipeline fails to schedule the next cycle. Coincidence? I think not. However, this part of the rufus scheduler error really throws me off.
> TZInfo::PeriodNotFound: 2022-03-27 02:27:00 is an invalid local time.
Where is the scheduler getting this timestamp from? Has anyone any experience with this?
Any help / direction is greatly appreciated!
---
### Author:  [@Badger](https://discuss.elastic.co/u/Badger)
#### Post date: [July 15, 2021, 3:58pm UTC](https://discuss.elastic.co/t/rufus-scheduler-error-tzinfo-periodnotfound/278811/2 "2021-07-15T15:58:13Z")
> [@chris\_ts24](#):
>
> TZInfo::PeriodNotFound: 2022-03-27 02:27:00 is an invalid local time.
I cannot say why the scheduler is generating that time, but the reason it is invalid is probably that your server is in a location (e.g. Albania, or Denmark) where daylight savings time starts at 02:00 on 2022/3/27, and 02:00:00 is immediately followed by 03:00:01. 02:27:00 does not happen.
---
### Author:  [@chris\_ts24](https://discuss.elastic.co/u/chris_ts24)
#### Post date: [July 15, 2021, 6:01pm UTC](https://discuss.elastic.co/t/rufus-scheduler-error-tzinfo-periodnotfound/278811/3 "2021-07-15T18:01:08Z")
Strangely, as the recorded JDBC timestamps show, the timestamps are written at least 21 minutes past 2am CEST. I would understand that Logstash prevents the timestamp write if it did it for all times past 2am, but if it's already writing at 2:21am, why stop suddenly at 2:27 due to an issue that will become a problem on the 27th of March, 2022?
I assume that the jdbc plugin can be used on a minute schedule, but wherein lies the problem with my implementation? Do I perhaps need to incorporate the timezone into the schedule, as [here](https://www.elastic.co/guide/en/logstash/current/plugins-inputs-jdbc.html) with the cited example `0 6 * * * America/Chicago`?
---
### Author:  [@chris\_ts24](https://discuss.elastic.co/u/chris_ts24)
#### Post date: [July 26, 2021, 12:12pm UTC](https://discuss.elastic.co/t/rufus-scheduler-error-tzinfo-periodnotfound/278811/4 "2021-07-26T12:12:58Z")
I have in the meantime found the reason for the problem, albeit an unexpected one that took a bit of digging into our database data.
The pipeline was attempting to rewrite all timestamps from the database into the timezone CET. This was, as @Badger has indicated, a problem because any timestamp between 2 and 3 in the morning on the 27th of march will not exist, as time will roll forward. So, how did we deal with this?
After some testing, it seemed that the conflict was occurring between how our machines were storing / retrieving timestamps from the database. So we removed jdbc timezone information from our configuration, which then defaults the timestamp to UTC. Then, looking into our database properties, we noticed that our DB is set in UTC, so we should never have been using this argument, as according to the [jdbc plugin docu](https://www.elastic.co/guide/en/logstash/current/plugins-inputs-jdbc.html#plugins-inputs-jdbc-jdbc_default_timezone), `If your database timezone is UTC then you do not need to set either of these settings.`
The remaining step was to find another strategy of saving the metadata timestamp, so that it too was saved in UTC. After struggling to get the query run timestamp to be saved in UTC and understood as UTC in the next scheduled run, we ultimately decided on saving the timestamp by tracking the modification timestamp column of our jdbc requests. In other words, the metadata timestamps are now saved in a timestamp format from the DB Column, as opposed to the timestamp Logstash saves in local time.
```auto
input {
jdbc {
jdbc_driver_class => "Java::oracle.jdbc.driver.OracleDriver"
jdbc_driver_library => "/usr/local/bin/ojdbc8.jar"
jdbc_connection_string => "jdbc:oracle:thin:@"
jdbc_user => ""
jdbc_password => ""
statement_filepath => "//"
schedule => "* * * * *"
last_run_metadata_path => "//"
enable_metric => false
tracking_column => "date_changed"
use_column_value => true
tracking_column_type => "timestamp"
}
}
```
To any struggling with timestamp issues, I would suggest finding a way to bring all your timestamps into a singular TZ to avoid this struggle, especially if you're using these metadata timestamps in your SQL WHERE clause. UTC is naturally the TZ of choice, as you won't have to worry about these DST problems from timestamps that don't exist.
I hope this helps! If confusion arises from this description, please let me know so I can make this more readable. These TZ issues are extremely frustrating.
Good luck!
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [August 23, 2021, 12:13pm UTC](https://discuss.elastic.co/t/rufus-scheduler-error-tzinfo-periodnotfound/278811/5 "2021-08-23T12:13:03Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.