1

I have a couple of Azure WebJobs which should fetch some entities from DB, when a given timestamp on the entity is passed. The problem is my timezone (GMT+1 - Denmark) where there is a 2 hour difference as of now (DST). So the WebJobs are currently fetching 2 hours too late. In the services I use DateTime.Now as a marker for current time. The timestamp in DB looks fine. I need to figure out how to make them in sync, and preferably without having to rewrite the entire service to DateTime.UtcNow instead.

I have added the WEBSITE_TIME_ZONE application setting in Azure and set it to Romance Standard Time, which should be correct and should fix the problem according to other posts, but this does not help.

Microsoft Azure,Webjob, in which timezone a webjob runs if I schedule a webjob to run daily at specified time using cron expression

C# code snippet from service:

var now = DateTime.Now;

var orderBatch = await db.OrderEntities
  .Where(o => o.OrderStatus == (int)Status.Accepted)
  .Where(o => o.ExecutionTime.HasValue && o.ExecutionTime < now)
  .Where(o => (o.NextSendTry == null || o.NextSendTry < now))
  .Select(o => new
  {
    OrderId = o.Id
  })
  .Take(100)
  .ToListAsync();

Log snippet from WebJobs logs where the current time was 04:38 and not 02:38. There is one order with execution time to 03:00, so it should have been fetched, but was not until 05:00:

[06/29/2019 02:38:21 > 98c279: INFO] 2019-06-29 04:38:21.618 +02:00 
[INF] 0 orders fetched from db @ 6/29/2019 4:38:21 AM

The web app should have the Romance Standard Time, and the WebJobs running in this app service should have the same timezone. Therefore DateTime.Now should be the servers (Azure web app) current time.

----- UPDATE -----

According to Matt's comments, we tried using UTC times in the service by converting our DB times on run-time with the .toUniversalTime() extension and then checking it againt DateTime.UtcNow. It is working fine, and the times in DB are still local times as we want them to be.

petemachine
  • 11
  • 2
  • Hi. Happy to help, but there's a lot of missing detail. Can you tell us what the data types are of `ExecutionType` and `NextSendTry`? What about the corresponding types in the database? I assume this is Azure SQL DB? Or is it something else? Are the values in the database also in terms of Denmark local time? Or are they in UTC? Thanks. – Matt Johnson-Pint Jul 03 '19 at 15:56
  • Also, is there a good reason you can't write the service to use UTC times? It is a much better practice. Even if you get this working, you will have potential errors during the DST fall-back transition. In your case, when either the order time or "now" is `2019-10-27 02:00`, your code won't know if that's the first instance (UTC+2) or the second instance (UTC+1). I usually tell people to do their best to *not* rely on `WEBSITE_TIME_ZONE`. It does work in most cases, but it is a crutch. Lean on it only when you absolutely must. – Matt Johnson-Pint Jul 03 '19 at 16:00
  • Hi @MattJohnson. Thanks for replying! ExecutionTime and NextSendTry are both of type DateTime. They are stored as datetime in the DB. The DB is an Azure SQL DB. Yes, the values correspond to the values as of local timezone. In our backend system we do not store the times as UTC, and that is also why we dont use UTC to check for in the service. Use of UTC is potentially a big change to our codebase. That is the reason for searching for at different solution. It has never been an issue outside of Azure. – petemachine Jul 04 '19 at 06:50

1 Answers1

0

I'd suggest to use DateTimeOffset(.NET)/datetimeoffset(SQL) data type instead of storing timestamp as DateTime(.NET)/datetime2(SQL) in your database.

Then you can set in OrderEntity property ExecutionTime to DateTimeOffset.Now or new DateTimeOffset(DateTime specificTime) and do the same thing for your webjob code.

The comparison will take into account timeshift between time zones.

Hope it helps. Cheers!

dropoutcoder
  • 2,627
  • 2
  • 14
  • 32