HangfireIO / Hangfire

An easy way to perform background job processing in .NET and .NET Core applications. No Windows Service or separate process required
https://www.hangfire.io
Other
9.32k stars 1.69k forks source link

Is Hangfire version 1.8.5 issue? #2295

Closed guytechNet closed 5 months ago

guytechNet commented 11 months ago

Hi all, I want setup a scheduler job so that it will auto run at 01:00:00 AM everyday (TimeZoneInfo.Local as GMT+7 -> My PC or My Server ) My code public IActionResult Index() { RecurringJob.AddOrUpdate(() => Console.WriteLine("Transparent!"), Cron.Daily(1, 0), new RecurringJobOptions { TimeZone = TimeZoneInfo.Local }); // TimeZoneInfo.Local as GMT+7 -> My PC or My Server return View(); }

I saw Hangfire version 1.8.5 has been saved CreatedAt and NextExecution incorrect so that it got to view correct. Why?

Field Value NextExecution 1695405600000 -> It execute my job at 18:00:00 PM of now -> I not want it.

Attach picture hangfire_dashboard

hangfire_dashboard2

hangfire_dashboard3

odinserj commented 11 months ago

I see that dashboard shows the expected time, 01:00 AM, according to the first screenshot. Is this correct? As for the database values, Hangfire always persists date/time values in UTC, and performs date manipulation on the server side, with database as a time authority whenever supported (like with SQL Server and Hangfire.Pro.Redis).

guytechNet commented 11 months ago

Hi odinserj,

The first screenshot is correct (I want it) but I checked history runtime of Hangfire is incorrect (Hangfire Recurring Job has been executed at 18:00 PM everyday -> incorrect). So I checked data of Hangfire Recurring Job at database Hangfire (Hangfire.Hash table so that I got result picture above). My server has Time Zone GMT+7. How do I do?

odinserj commented 11 months ago

So if database entries contain an 18:00 PM value, then local time for +7 is 01:00 AM as expected, so history looks correct.

guytechNet commented 11 months ago

You're incorrect. My local time for GMT+7. I want a Recurring Job 01:00 AM everyday. This is my code as follow

public IActionResult Index() { RecurringJob.AddOrUpdate(() => Console.WriteLine("Transparent!"), Cron.Daily(1, 0), new RecurringJobOptions { TimeZone = TimeZoneInfo.Local }); 
return View(); }

But I checked history runtime of Hangfire Recurring Job is incorrect. I checked data of Recurring Job at database Hangfire (as Hangfire.Hash table so that I got result picture above) I thinked a logic of Hangfire insert data without TimeZoneInfo.Local. Can you review it?

odinserj commented 11 months ago

Hangfire persists everything in UTC format, performing local time calculations between storing the value and restoring it back. Storing a date/time value in a database in a local format will lead to errors when the server's time zone is changed or when different recurring jobs have different time zones specified. So this is by design.

Each recurring job has its assigned time zone also recorded in the same hash. So when Hangfire reads the UTC value from database, it converts it to a specified time zone first. So, in your case, it will read the 18:00 value and add +7 hours before using the value, resulting in 01:00 AM as expected.

guytechNet commented 11 months ago

Hangfire persists everything in UTC format, performing local time calculations between storing the value and restoring it back. Storing a date/time value in a database in a local format will lead to errors when the server's time zone is changed or when different recurring jobs have different time zones specified. So this is by design.

-> I find that your logic designs are too complicated and confusing for users. Why not consider the values that users initialize into the Hash table to be the configuration values that users want so that it excludes the server's time zone being changed or are there other time zones specified? -> It means input and output by configuration values of users.

Each recurring job has its assigned time zone also recorded in the same hash. So when Hangfire reads the UTC value from database, it converts it to a specified time zone first. So, in your case, it will read the 18:00 value and add +7 hours before using the value, resulting in 01:00 AM as expected.

-> The next time you receive a configuration value that is not added +7 hours before using the value.