Improve Local time support in Orion

[jmcanterafonseca]

It would be great to improve local time support in Orion after #2660 lands.

This is important because we expect to have a myriad of data belonging to local scopes (cities, countries), etc. and users and developers would expect a decent support of local date and times.

We have the following options (we can support both):

A/ Support the Timezone experimental HTTP header or a variant of it (Fiware-Timezone) and be able to provide data localized to what a client is requesting and interpret timezoneless data as referred to such local timezone.

https://tools.ietf.org/html/draft-sharhalakis-httptz-05

B/ Instantiate Orion (global parameter) with a default timezone that will be used anytime a timezoneless datestring is used.

What do you think?

[fgalan]

Both A and B are compatible?

I mean, if the client specified Fiware-timezone then Orion will return the datetime in client's timezone (option A). If the header is not provided, then Orion returns the datetime in the timezone corresponding to the global parameter (option B).

With regards to B, in order to ensure backward compatibility default timezone in the case of not using the global parameter must be UTC.

[fgalan]

@LeonanCarvalho feedback on this topic, raised at #2660 (comment):

By default all http servers that I worked (Apache, Nginx and lighttpd) expose a header called date this one express the server date time, and can be used to guide the context date time when a UTC/Zulu or GMT is not applied.
All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception. HTTP applications are allowed to use any of the following three representations of date/time stamps:

• Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
• Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
• Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format

The first format is the most preferred one as described on rfc2616.

When you need to work with different timezone (eg. Brazil have 3, UTC -2, UTC -3 and UTC -4) you must have a base and then calculate + or - many hours to present to end-user.

[fgalan]

This issue is not especifically related with NGISv2, so APIv2 label is removed. The issue keeps opened.

CC: @jmcanterafonseca