By default, the timezone of an Azure Function app is UTC/GMT +0 or Greenwich Mean Time. This is great if that is your timezone or the timezone you want your application functions to run in, but for most of us, we need to either adjust all our schedules to fit that timezone or we need to change the timezone.

Luckily, the solution is actually pretty simple. It doesn't even involve coding anything.

## Changing the Timezone

All function apps have a set of configuration settings that can be applied in the settings through the portal:

![azure-function-timezone-setting](/assets/screen-shot-2022-02-18-at-9.26.53-pm.jpg "Set the Azure function timezone")

One of these settings is WEBSITE_TIME_ZONE, which as the name suggests, allows us to define the timezone of the web application that runs behind the scenes of all Azure Function apps.

Azure provides us two options when creating a function app:

1. We can create a Windows-based function app, or,

2. We can create a Linux based function app

If you have or create a Windows app, all the available options for the timezone setting values can be found in the official [Microsoft Docs](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc749073(v=ws.10)).

For Linux, we need to fall back to the Linux database timezone information provided in Wikipedia, which can be found [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

So, for me, as I am East-Coast Australia based, I would configure my apps:

For Windows -

![Azure-funtions-app-timezone-setting](/assets/screen-shot-2022-02-18-at-9.36.16-pm.jpg "Set Azure functions Timezone Setting")

And for Linux -

![Azure-funtions-app-timezone-setting](/assets/screen-shot-2022-02-18-at-9.37.02-pm.jpg "Set Azure functions Timezone Setting")

## Testing

The easiest way to test & confirm that the timezone has taken effect after saving is to leave the default log statement that a new function comes with:

context.log('HTTP trigger function processed a request.');

This will appear in the logs with a timestamp. You will be able to confirm that the date & time displayed matches that of the configured timezone.

## Testing Locally

If you need or want to test your functions in different timezones from your lcoal machine setting, the Azure Functions local.settings.json also interprets the same configuration setting.

This means you can add

"WEBSITE_TIME_ZONE" : "GB" (for Linux)

to your local.settings.json file. When you execute your functions locally, the timezone applied to the date-time objects in your code will apply the Great Britain timezone.

By default, the timezone of an Azure Function app is UTC/GMT +0 or Greenwich Mean Time. This is great if that is your timezone or the timezone you want your application functions to run in, but for most of us, we need to either adjust all our schedules to fit that timezone or we need to change the timezone.

How to Set the Timezone of an Azure Function App

### What is an HTTP Interceptor?

Every HTTP transaction that occurs between the client and server of web applications has a request and a response.

The client requests something or sends something to the server. The server processes this and responds with a response.

HTTP Interceptors allow the client application to modify either (or both) the content of the request and response. For those familiar with Nodejs, the HTTP interceptor is not too dissimilar from Express middleware in that it acts as a middle-man to the requests.

### Common Uses

The most common use I come across in general development is to add JWT access tokens into the outgoing request headers for a server to validate with. Generally, this will mean accessing the JWT from wherever it is being stored (hopefully not local storage) and appending a new header value with the correct name for the server to accept, validate and continue with the request.

The other common use I have implemented is to add additional data into the response object. Generally, this will be a piece of information that is required for all responses to be processed by the client, but not actually data that needs to make the trip to and from the server. This could be a local user Id or email address, or some other display-only data.

### Adding the Interceptor

Assuming you already have an Angular app spun up, adding the interceptor itself is relatively trivial.

In my projects, I either create a new provider in a servers/providers folder or a separate folder just for the interceptor:

~/angular-app/src/app/services/http-interceptor.service.ts

or

~/angular-app/src/app/interceptors/http.interceptor.ts

But either way, the file needs to be a provider file as per Angular providers.

The implementation of this file at a base level is very simple. The service class must implement HttpInterceptor from the "@angular/common/http" part of the Angular framework. This brings in the requirement to have a function definition of intercept() which handles the request modification:

```typescript
import { Injectable } from '@angular/core';
import { HttpInterceptor, HttpRequest, HttpHandler, HttpEvent } from "@angular/common/http";

@Injectable({
  providedIn: 'root'
})
export class HttpInterceptorService implements HttpInterceptor {
  constrcutor() { }
  
  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> { 
    let headers = request.headers.append('Content-Type', 'application/json');
    const requestClone = request.clone({
            headers
          });
    return next.handle(requestClone);
  }
}
```

In the above example, we're simply adding the Content-Type header to all outgoing requests.

The real magic is the request.clone() function. As it says, it creates a new copy of the outgoing request and allows us to modify it before using it as the outgoing request information.

In addition to the above file, in order for the interceptor to fire correctly, the Angular module needs to be updated to tell the app the interceptor exists. So, in the app.module.ts file you will need to add an additional provider:

```typescript
import { AppComponent } from './app.component';
import { HttpClientModule, HTTP_INTERCEPTORS } from '@angular/common/http';
import { HttpInterceptorService } from './services/http-interceptor.service';

@NgModule({
  declarations: [AppComponent],
  entryComponents: [],
  imports: [...],
  providers: [
    ...,
    { provide: HTTP_INTERCEPTORS, useClass: HttpInterceptorService, multi: true }
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }
```

That's all there is to it. The logic of the intercept function should do all the work required to modify the request.

An HTTP interceptor is a piece of logic that is able to attach to a HTTP request or response. This logic can then modify the data being transferred.

How to setup an Angular HTTP Interceptor

Being a software developer of any flavour opens a wide range of possible income sources to you so that you can invest your time and energy in creating  the lifestyle you desire.