We source data from a number of large national, and trans-national, statistical bodies, like the Office of National Statistics here in the UK, or Eurostat. Downloading useful data from organizations like this is sometimes a tricky job – although publishing data is usually part of their raison d’être, they’re not usually thinking of people like us – Big Data geeks – when making their data available. And often, their methods of making data available have been essentially unchanged for the past ten or fifteen years, and even then are probably based on processes predating the Internet.

One of the sources of value Timetric adds is simply making this data more widely available and accessible. But it’s also true that there’s so much more we could do if we could put our minds to using this data in new and exciting ways, rather than expending expertise on working out the best way to map old-fashioned data publication workflows to a web-centric way of working. So it’s an interesting question to ask – in an ideal world, how would a large statistical organization publish data for us?

There’s three aspects to this question:

1. Data transfer and formats
2. Metadata formats and reconciliation
3. Update frequency and notifications

1. Data transfer and formats

For us, the easiest data to deal with is probably — and perhaps counter-intuitively — either the ONS or Eurostat. That’s despite the fact that both of these present their data in fairly obscure, more-or-less undocumented dumps of 1980′s-era databases (at a guess).

However, in both of these cases, we can download the entire database in just a few files, largely one per data release, each containing several thousands, to tens of thousands, of series. We don’t have to run any queries to express which data we’d like, everything simply lives at a predictable URL. We don’t want to make hundreds of queries to get different subsets of the data, we mostly just want it all (though see below).

The formats and the URL schemes could be documented much better — but we’ve already done the job of reverse engineering them. As long as they don’t change significantly, it’s a trivially-repeatable set of operations to get the files, and extract the data from them. And each source is yielding a huge quantity of valuable data, so for that up-front investment in time, we get a good payoff.

For a new source, we’d be quite happy with anything along those lines. We don’t mind a bit of time in writing a parser for a new data format, or even in reverse-engineering some URL construction. That up-front cost isn’t a huge investment if there’s a lot of high-quality data, repeatably downloadable, waiting for us afterwards. That said, obviously we’d much rather have the data in a well-documented, simple format, and minimize that up-front investment. You can’t go very far wrong with CSV files lying behind well-established URLs.

What we really don’t like is API endpoints built around the idea that you only want a few series at a time, and you’ll be making the choice by hand. It’s no fun doing thousands of HTTP connections to get each and every data series (neither for us, having to track success/failure/retries – nor for the servers, having to deal with us flooding their API). It’s also no fun trying to work out various combinations of query parameters until we get just what we want. That’s especially painful when they’re query parameters for forms designed originally to be driven by human interactions. But even when they are aimed at computer downloads, there’s still far too many API developers who still haven’t thought about API discoverability. (And we definitely don’t want these forms submitted by POST. Bang, there goes your cache, and our chances of getting data quickly.) All in all, we’d rather just have data dumps to download.

In short, APIs which are good for exposing small quantities of data to individual users aren’t very good for exposing large quantities of data for reuse on a large scale. And formats don’t really matter at all.

2. Metadata schemata, formats, and reconciliation.

Again, surprisingly, there’s something to be said for the Eurostat approach to this – but this time not the ONS. Eurostat have a fairly cryptic set of metadata codes, encoded in a rather bizarre way within the data, which only directly apply to their own data, and are probably the result of several decades of semi-random accretion. There’s no international standards in use here. On the other hand, they are well-documented, and once you’ve worked out how to extract and decode them, you’ve got a nice, consistent set of metadata across tens of thousands of data sets. That’s a far better state of affairs than some data suppliers, who give us little or no metadata, and certainly don’t have a well-documented background to their metadata terms (collection methods, statistical processes, industrial classifications etc).

(The ONS, by comparison, are not useful in this regard. They are very precise about their metadata, and have reams upon reams of well-written documentation about statistical standards. However, almost none of this metadata can be linked up with their data in any automatic way. The data themselves come with nothing except very short titles, often with enigmatically and inconsistently abbreviated technical terms.)

If you’re a large well-established national or trans-national body, and you’ve got your own internal metadata — please just expose it! At least that way, we can arrange all your data consistently with respect to itself, and probably start linking the obvious bits of metadata across multiple sources. We’d much rather have that now, than wait on a perfect standard further down the road.

On the other hand, if you’re starting from scratch these days, you could do much better. Our lives would be made much easier if people used metadata which was drawn from some standardized vocabulary, so we could reconcile metadata between different suppliers. If you were beginning the process today, the obvious place to start now is with SDMX (and see the tutorial from the European Central Bank).

At the moment, we have to do lots of that reconciliation ourselves. You can automate surprisingly large amounts of the work, but by no means all. It definitely still requires human intervention, and often from someone who’s fairly economically literate. Enormous amounts of the work we’ve done has gone into building tools to let us leverage that human intervention as much as possible, to develop semi-automated workflows for metadata reconciliation.

In short, ideally, everyone would use internationally-recognized standards of metadata and reporting. But if they don’t, or can’t yet, the most useful thing they can do now, is to make as much of their internal metadata systems documented, available for reuse, and mark up as much of their data with it as possible. Making that available now would be an immediate gain for everyone. Waiting around for people to map their internal metadata systems on to SDMX doesn’t help anyone nearly as much.

3. Update frequency and notifications

For most data providers on this scale, different series are updated at different times, on different release schedules. A naïve approach to dealing with this is to simply download the entire dataset daily, and reprocess it to find what’s changed. This has the problem that:

• it costs us quite a bit of processing time, much of which is entirely unnecessary, meaning data isn’t as available as quickly as it should be,
• it costs the data provider in terms of bandwidth on data that’s downloaded unecessarily, just so we could check it’s not changed,
• it leaves open the question of *when* we should do this downloading. We want the data as soon as its released – but we have no way of finding out when that is. All we can do is download frequently enough that we aren’t likely to be too slow in catching new data (while not running afoul of either of the other two problems).

There are various ways around this. The ONS, for example, always makes data releases at 09:30 UK time (or very shortly thereafter), so that’s when we check their site. Unfortunately, they don’t tell you (in a machine-readable way) what has changed, so we still have to process an awful lot of unchanged data.

An easy way for them, or indeed anyone, to do this right is just to use HTTP timestamps on data dump files. We could simply do a HEAD on the URL, check whether the data has changed, and download the contents only if they were new.

If they wanted to be even more helpful, they could provide notification services for us to subscribe to, letting us know as soon as data was updated. But to be perfectly honest, I wouldn’t be very concerned with them doing that. It’s another moving part to go wrong, and I’d still be very tempted to poll their URLs anyway to check that there weren’t updates being provided which notifications weren’t working for.

Finally, if I were a data provider, I’d make very sure I had a good cache in front of everything. If you are doing what we want in terms of data dumps, then there’s nothing easier to cache than GETs to a set of unchanging URLs, with relatively-infrequently changing contents at each URL. Even if you are using something else, then caching should be an important part of your technical strategy.

People make mistakes, and they will end up accidentally downloading too much, too often, or accidentally letting a badly-written client run loose. You can shout at them and deny them access, but nobody’s going to be happy about that, whoever’s fault it is, and that’s still going to leave you open to the risk of people overloading you before you get round to banning them. (See the police.uk fiasco for how not to handle this!)

Thinking about your users

Sometimes I wonder if perhaps we’re atypical of the sorts of users that statistical organizations need to deal with — but on reflection, I don’t think that’s true. (and to the extent it is, I believe we’re in the vanguard of a much broader spectrum of people who want to reuse data like this.) We’re probably higher volume than most users right now, but we’re probably also more likely to be prepared to deal with poorly designed systems, and persist when many wouldn’t. Organizations that put time and effort into making data useful to users like us will find their data much more widely used than those who don’t.

Ultimately, if an organization like we’re discussing here wants to make its data more useful to everyone, there’s one big lesson to be learnt, and that is: “You’re not going to be able to predict what your users want”. The best job a public data organization can do is make as much of the data (and metadata!) available as it can, in as untrammelled a form as possible. Don’t try and second guess what people want to do – just let them have everything. As long as you don’t stand in their way, people will use and re-use your data in ways you could never have foreseen.

A lot of our pages now have an email button:

If you click that button where you see it, and fill out the form, we’ll handle the rest. Here’s how it works:

And your friend will get an email like this:

Really simple and, we hope, really useful. Let us know what you think.

We launched Timetric Portfolios a couple of weeks ago, and we’re delighted to see people using it to track their investments (or just work out how a set of shares would have done).

Now you can carry your portfolios around with you, too: Timetric Portfolios for iPhone (or iPod Touch)!

Get it from the UK or US app stores.

Timetric is delighted to announce that it has recently closed an investment round. Participants in the round included Stefan Glänzer, Alex Zubillaga, Sherry Coutu, Matteo Stefanel and Sean Park and Udayan Goyal of Nauiokas Park. Timetric intend to use the capital raised to accelerate the rollout of their network of novel statistical services.

About Timetric

Timetric build services which make statistics useful. They include timetric.com, a leading aggregator of public statistical data, and Timetric Portfolios, a radically simple and social tool for analysing stock portfolios. All of their services are built on top of the Timetric Platform, their class-leading proprietary service for publishing, analysing, and performing calculations on very large quantities of time-varying statistical data. Their customers include the Guardian and United Business Media.

Timetric was founded by Andrew Walkingshaw, Toby White and Dan Wilson in mid-2008. They were winners at London Mini Seedcamp 2009; the company is now based in Clerkenwell, London, having relocated from Cambridge towards the end of last year.

Enquiries to press@timetric.com.

Timetric Ltd is a company registered in England and Wales, number 7133675, with registered office address Level 9, 107 Cheapside, London EC2V 6DN.

We’re on Techcrunch Europe too! Big day for us.

And with that, two more bits of news. We launched Timetric Portfolios, and you should check it out. Also: we’re hiring. Get in touch!

These are both reflections of one of the biggest changes we’ve made – we’ve entirely replaced the search infrastructure the site runs on. We’re now backed by Apache Solr, and we’ve written a new Python-Solr interface, called sunburnt.

We let users search using both free text search and drill-down tagging — we used to run these on a combination of postgres-backed full-search text and django-tagging, but this combination wasn’t particularly satisfactory. Unsurprisingly, when you’re trying to add search infrastructure to a site, what you really want is a proper search-engine backend.

For a mature, full-featured, well-supported open-source search engine, the choice boils down to Solr or Xapian. We were strongly tempted by the latter — there’s no shortage of Xapian expertise around Cambridge, but we were swayed by the Apache licensing of Solr, rather than Xapian’s GPL.

And although there are a number of existing Python-Solr interfaces, none of them did what we wanted, which was to provide an intelligent and robust Pythonic API, which lets you pass arbitrary objects in and out of Solr. So we built our own, and called it sunburnt.

Sunburnt is most directly comparable to Haystack, but with a couple of major differences. Firstly, it’s not restricted to Django model data, and secondly, it’s schema-driven rather than schema-generating — it lets you construct your own Solr schema, and automatically derives all the type-checking/conversion/coercion code necessary to map your objects to and from the Solr index, when constructing queries and exchanging data.

The only documentation at the moment is the examples below, but the code is all up on Github. Patches and contributions are more than welcome!

Sunburnt in use

To start indexing & querying, you initialize a SolrInterface with your schema. At the moment, you need to do this by passing in the schema xml — sunburnt won’t query the Solr server for its schema.

solr_interface = sunburnt.SolrInterface("http://localhost:8983", "schema.xml")

To index objects, add() them to the interface. sunburnt doesn’t care what form the data comes in, so long as

• if it looks like an object, it has attributes named according to fields defined in the schema
• if it looks like a dictionary, it has keys named according to fields defined in the schema

class Document(object):
    def __init__(self, title, contents):
        self.title = title
        self.contents = contents
 
documents = [
   {"title":"This is a dictionary", "contents":"Lorem ipsum"},
   Document("This is an object", "dolor")
]
 
solr_interface.add(documents)

If you haven’t set your Solr instance up to do autocommit, then you might want to commit your documents to the index:

solr_interface.commit()

after which the documents are searchable. The API is fairly close to that offered by Haystack (and indeed Django’s QuerySet) – unsurprisingly, since they’re solving similar problems.

solr_interface.query("This")

does what you might expect, searching on the default field.

solr_interface.query("This").filter("dictionary")

while chaining with filter() allows you to choose which parts of your queries are cached by Solr.

For fields representing numbers, or dates, then searching by range is useful, for example

solr_interface.query("This", last_modified__gt="2009-01-01")

if you have a last_modified field in your schema. Queries can be faceted – if you had tags on your objects, you might do this:

solr_interface.query("This").facet_by("tags", limit=20, mincount=1)

and if you wanted to search for similar documents, you can do a more-like-this query (in this case, looking for similarity in the tags field)

solr_interface.query("This").mlt("tags")

sunburnt doesn’t support all of the Solr API, but it gives you access to a goodly portion, and all of these operations are chainable.

solr_interface.query("This").filter("dictionary").\
    facet_by("tags", limit=20, mincount=1).\
    query(last_modified__gt="2009-01-01").paginate(rows=10)

Finally, having set up a query, you can get a result object back by execute()ing the query. This bit of the API is still a bit rough around the edges, but

r = solr_interface.query(...).execute()
r.result # has the main query results
r.facet_counts # has the faceting results
r.more_like_these # has any more_like_these results

and if you poke around in that object, it has all the rest of the information that Solr provides.

Sunburnt in practice

The code is now running live on Timetric, and is problem-free for us. We’ve been able to throw away scads of code working around djangosearch/django-tagging shortcomings, and performance is significantly faster all round, especially for anything regarding tagging. Most usefully though, it’s provided us with a platform to start experimenting with new navigation features much more rapidly.

Postscript: djangosearch/django-tagging shortcomings

djangosearch, though easy to set up (if you’re already using postgres), offers very little in the way of control over various parameters and options you might want to tune, and requires filtering/escaping of some queries. (Searching for a string with “£” in it causes interesting errors!)

django-tagging had slightly more serious issues;

• we had to maintain our own fork of the codebase due to a couple of long-standing issues; corner cases which upstream weren’t interested in fixing (One that kept biting us was its lack of support for models with non-integer primary keys. Easily fixed, but support is still not included in upstream django-tagging).
• extending its functionality turned out to involve writing a lot of hand-tuned and often inherently slow SQL. Writing related-tags functionality was particularly painful – it involves inverting the index, which is very time-consuming – we had to do that offline.

As of last Monday, we’ve upgraded timetric.com to cope with the OAuth 1.0a workflow.

If you follow these things, you can hardly have avoided noticing that there was a big fuss in April this year, when a vulnerability in the OAuth protocol was discovered. When it was made public, it turned out to be less a technical than a social vulnerability. The OAuth workflow involves several transactions, and the exchange of multiple tokens. In version 1.0, there was an opportunity for a malicious third party to step into the exchange, and by tricking the end user (essentially, by phishing them into clicking a link) gain their credentials.

Still, social vulnerabilities are as important as technical ones, and the OAuth team rapidly developed version 1.0a of the workflow which avoids the problem. In the interim, and since upgrading existing servers and clients is hard work, and since the issue can be mitigated by anti-phishing provisions, it’s been standard practice to carry on supporting the 1.0 workflow, while attaching big warnings everywhere, and that’s what we’ve been doing.

However, we’ve now finished implementing a 1.0a-compliant server for timetric, so that 1.0a-capable clients can take advantage of the improved workflow. But because most clients don’t yet support 1.0a, our server currently supports both 1.0 and 1.0a transactions. Doing this has involved borrowing from, and extending, both python-oauth & django-oauth. We’ve fed our changes to both the upstream authors of both projects, we’ve tested our codebase, and it’s now running live on timetric.

(As of writing, our changes haven’t yet made it into the upstream version of django-oauth, but you can get a hold of what we’ve done from our fork on github.)

We’ll continue to support the 1.0 workflow for the immediately-foreseeable future, but obviously at some point we’ll want to retire it in favour of the more secure 1.0a. For those of you who’ve written OAuth clients , I can highly recommend this blog post as a very nice overview of the changes in the workflow, and what you need to do to 1.0a-enable a client.

OAuth autodiscovery

While I was poking around with the OAuth code, I also managed to address a niggle I’ve had for a long time with OAuth. Oauth uses three separate URL endpoints to manage the token request/exchange process. These need to be published somewhere, and then any OAuth clients need to know these service-specific URLs. This is annoying; practically, because it makes it hard to write a generic OAuth client framework, and also it offends the RESTian purist in me – resources should be machine-discoverable, dammit.

Anyway, it turns out that there is an experimental OAuth auto-discovery spec, which piggybacks off the XRDS resource discovery scheme. It’s not final, and it seems there’s not a lot of active development on it, but I thought I’d try it out anyway. Having implemented it as an experiment, I’m actually quite happy with it. All timetric OAuth resources are now completely auto-discoverable, knowing nothing but the xrds mimetype.

The workflow goes like this: firstly, ask for the location of the XRDS resource description, by using content-negotiation on whatever OAuth-protected resource you’re trying to gain access to:

Request:
GET /resource-of-interest
Accept: application/xrds+xml

Response:
HTTP/1.1 302 Found
X-XRDS-Location: /xrds.xrds
Location: http://timetric.com/xrds.xrds
[...]

then follow the redirect;

Request:
GET /xrds.xrds

Response:
HTTP/1.1 200 OK
Content-Type: application/xrds+xml
[...]

<?xml version="1.0" encoding="UTF-8"?>
<XRDS xmlns="xri://$xrds">
[...]

The XRDS file has a well-defined XML format, and the client can parse it to pull out the location of the OAuth endpoints. This means that you can write a very generic OAuth client library; all the library needs to be told is the location of any interesting oauth-protected resources, and now it can find out everything it needs to negotiate the OAuth workflow. Helpfully, you can also use the XRDS file to advertise which forms of OAuth negotiation you support – parameters in the URI, or as HTTP headers, different signature schemes, and so on.

I’ve had an immediate benefit, because now it’s made my test framework much simpler – I don’t need to store arbitrary strings denoting my OAuth URLs, nor manipulate them every time I run tests against differently-named test servers. Since the spec isn’t final, this scheme is obviously liable to change – but it’s a nice example of how to make a service machine-discoverable.

Previously our API was basically only let you add and retrieve data. This has been useful to a whole lot of people, but there’s much more that you can do with Timetric.

The new release involves several features. There’s a bit of improvement to existing functionality to make life a bit easier when uploading data; but more excitingly, we’ve opened up access to even more of the capabilities of the timetric platform.

Search endpoints

When building applications on top of Timetric, one of things we’ve been asked for is the ability to retrieve lists of relevant data. This might simply be to get hold of all of your own series, or it might be a list of tagged series, or it might be a complex search query.

For all of these, we’ve exposed search endpoints that let you do powerful queries across our data. You can search through the full text of our titles and descriptions, over tags, and by user. This means you can build much more useful interactive interfaces on top of Timetric. In fact, these are exactly the same endpoints that timetric.com uses internally when you browse our data.

Calculated series

Through the timetric.com website, you’ve always had the ability to build model calculations, and to filter series. We’ve now exposed this at the API level as well, so you can build these models and filters programmatically.

Cross-domain requests

If you’re a web developer, you’ll be all too familiar with the headaches of restrictions on cross-domain requests. In many cases, there are perfectly good security-related reasons for them, but these restrictions make writing some web applications much harder than it ought to be.

Fortunately, the newest generation of browsers (Firefox 3.5, IE8, and Safari 4) let you make secure cross-domain requests directly — so long as the server supports it (see https://developer.mozilla.org/en/HTTP_access_control). Since this is such a useful feature — for us as much as anyone else – we’ve enabled it so you can use it too, and build much more exciting Timetric mashups in modern browsers.

Easier uploading

And finally, we had feedback from several people about ways in which we could make pushing data into the platform through the API a bit easier. The details are probably uninteresting unless you like constructing HTTP messages yourself (which I do, but it’s not everyone’s cup of tea!) so I’ll simply point you at the new documentation. In short, you can POST data directly, rather than having to multipart-encode it.

So …

If you’re a developer, get out there and play! We’re always happy to get any feedback – positive or negative!

The backstory is that Timetric runs on a pair of databases for its backend. One is a traditional RDBMS (Postgres, as it happens), which is used for storing all metadata; the other is a non-relational DB, used for storing all our timeseries data. It’s the latter which was at issue – we needed to make the fairly major change from using HBase to using Tokyo Cabinet/Tyrant.

When we first started building Timetric, we knew we wanted to use a non-relational DB for our timeseries data. There’s a number of options out there (for a recent overview, see Bob Ippolito’s talk “Drop ACID and think about data” at PyCon 2009). We did some initial experimentation, and ended up going with HBase. It seemed like a good match – it has timestamped versioning for all its data, which seemed to fit data that’s inherently time-based; it’s a high-profile project, at the time just adopted by Apache; it’s got a lively, helpful developer community; the codebase seemed relatively robust, and was comprehensible (so much so that despite not really being a Java programmer, I was able to offer a few minor patches easily enough). And it has a very nice scaling story, up to billions of rows, which is nice to have in reserve!

Its major downside was that its performance wasn’t really yet ready for use behind an interactive website – nevertheless, we were still in early alpha at the time. Performance improvements were high up the developer team’s wishlist, and we didn’t seem to be the only people interested in using it as backing store for a web application, so we had hopes that things would improve. and, indeed they did – current HBase performance is significantly better than it was 6 months ago.

Nevertheless, a few weeks ago, we decided that we couldn’t carry on working with HBase indefinitely; we took another look around, and made the choice to migrate to Tyrant.

There were a few reasons for this:

• HBase performance was improving, but it was becoming apparent that the loads we were placing on it were atypical; it was coping, but we were having to do some relatively baroque optimizations within the web application layer to get acceptable performance for large datasets.
• We’ve had people getting in touch about running private Timetric instances. For these, having one single, huge, database for holding all our data is less important – rather, we need multiple, per-instance databases. Scaling at the high-end is less important, and management at the low-end is more important; HBase isn’t trivial to manage – it’s got a lot of moving parts, and automating the management of large-scale deployments is a complex task (see, for example, SmartFrog).
• Most importantly, when you’re managing multiple instances, reliability becomes a far greater concern. Not that it’s more important, but there are more points of failure; managing that reliably is hard. HBase is a large system, with a relatively small user-base – while we’ve been in a position to deal with running it behind Timetric.com, we weren’t confident in our ability to do so behind multiple instances of the platform, for multiple customers.

Fundamentally, we need a much simpler, more easily manageable, and faster solution. Fortunately, Tyrant fulfils all of these criteria for us. 

• It’s astonishingly fast – so much so that we’ve actually switched memcached off in a number of situations, because it’s quicker simply to get the data straight from the source. (This is partly due to the fact that Django’s interface to memcached requires you to use pickle, which is orders of magnitude slower than using simplejson for simple data structures).
• Setup is ridiculously simple. Honestly, why can’t all databases be this simple? Compilation is a bog-standard “./configure && make && make install”, there’s literally no configuration necessary to get a database going which is optimised for most common use cases, and there’s one command to start & stop it.
• Despite some reasonably hard pushing at it, we’ve had no hint of data corruption – or even transaction failures – against Tyrant. And the knowledge that it’s been heavily stress-tested elsewhere gives a nice warm fuzzy feeling.

So, over the last few weeks, we’ve been planning this changeover; writing the new backend interface, testing, bugfixing, load-testing, optimizing, etc., with the aim of making the changeover today.

However, yesterday morning, events overtook us. The server logs started showing worrying error messages – the sort you really don’t like to see – about missing data. On further investigation, it turned out that our HBase instance was dropping data on the floor, left, right and centre.

Fortunately, we keep good backups!! I’ll emphasise that before going any further. (I should also note that we still have no idea why the data corruption started happening – although clearly it was HBase dropping the data, I’m not laying all the blame on its head; we haven’t had time to find out what might have prompted the problem.)

We deliberated briefly about what to do – we knew we had backups, and could restore them to HBase – we’ve tested that process before, so we knew how long it would take, a matter of a few hours. On the other hand, we’d been planning to do the migration the next day anyway. The migration would take a bit longer than simply restoring the backups; and because we’d been forced into it, would take slightly longer than was originally planned. On the whole, though, we thought it was best to cut our losses and kickstart the migration immediately.

So, the result was what you saw yesterday! Stress levels were fairly high all day (not helped by one of our number being in self-imposed quarantine – Dan came down with a cold (not swine flu!) yesterday morning, so kept himself at home, though he was working hard online. Nevertheless, the migration went almost entirely smoothly; much better than the worst case scenarios I’d dreamt up, and as you saw we were up again before the day was out.

And the result is fairly impressive, I think. Currently, most of the improvements are either fairly well-hidden, or amount to support for additional features which we’ll be building out in the next short while. But the most noticeable gain is that the whole site is much snappier now – page load times, especially for large series, have dropped dramatically. Upload times are hugely improved as well, which is letting us do some quite exciting things.

Unfortunately, though, we’ll have to take the site offline to move everything across. We’re going to do that this Friday (1st May); we’ll go as fast as we can, but you should expect Timetric to be offline all day, UK time, on Friday.

Sorry for the inconvenience!