Why we don't provide data in local time?

Why we don't provide data in local time?

Solcast Products

Grid Aggregations
Typical Meteorological Year (TMY)
Geographic Horizon Angles


Modelling - FAQsModelling - FAQs

Solcast API

Third Party Applications

Hobbyists and Researchers

Troubleshooting and FAQs

FAQsFAQsTroubleshooting Data ErrorsTroubleshooting Data Errors

Useful Links

Postman API (Spec) Documentation

API Change LogAPI Change LogSubscription ManagementSubscription ManagementAccount FAQs

UTC or Local Time?

Converting UTC to local time. How can I change the UTC to my timezone?

By default, all time series data that is accessible from the Solcast API is in Coordinated Universal Time, or UTC. We often get asked why we don't convert our data from UTC to a specific local time.

Firstly, what is our current format in?

You are likely to find Solcast exports in UTC with the timezone offset appended on the end of the timestamp format should you select longitudinal time for the export. These timezone offsets are to the hour of the allocated UTC based on the longitudinal position.

Please view the image below for timezone offsets.


Here's 2 reasons why we don't provide our data in local time:

Working with timezones is tricky

Whilst we relish the opportunity to get our hands dirty with a worthy challenge, working with dates is one of those problems that only keep on giving. There are some whom work with dates regularly and have published their opinions. Here is a sample:

  1. NodaTime Trivia (the author of a popular Date/Time library for many languages describes some of the edge cases he's found)
  2. The Time & Zone Fallacies believed by Programmers

As is the case for many businesses, there is only so much effort and resources available. We'd prefer to spend our effort towards improving our forecasting capabilities rather then getting bogged down in date complexities.

Which timezone?

Pushing past the complexities of dates, let's assume we'd go ahead anyway. If we decided to support automatic local time conversion, there are a number of different ways we could allow timezone to be configured within a request:

1. Via a fixed offset (e.g. +10 or -5)  2. Via a legal time zone (e.g. PST or AEST)  3. Via the longitude of the location in the request (e.g. 1 hour every 15 degrees)  4. Via a nominated TZDB ID (e.g. Australia/Sydney)

Each of these methods has their own advantages and disadvantages (which won't be discussed here). If we chose to support one of these, it may end up suiting a particular group of users, but may also frustrate another group of users.

How can we help you convert to local time?

We still want to help you convert time series data for your own use. You may want to validate Solcast data against one of your own data sets, and the difference between the dates in the two datasets is making a manual comparison difficult. You may be carrying out your comparison using Excel spreadsheets or files in csv format. If this is you, we have a tool for you that may help you out.


The above is a link to an excel spreadsheet that contains a tool to convert time series data retrieved from the Solcast API and applies a fixed offset to it.

The spreadsheet contains specific instructions on how to use the tool, but in a nutshell you would follow the below steps:

1. Within the csv file containing Solcast API data, copy the column containing the time series you want to convert. 2. Paste the time series into the first column of the solcast-timezone-converter spreadsheet 3. Identify the fixed offset you want applied to the time series data (10 or -5, or some other offset). The tool will then apply the offset to the time series into a new column 4. Copy and paste the updated time series data with applied offset back into your original csv file