New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Local time support in Orion #2663

jmcanterafonseca opened this Issue Nov 14, 2016 · 3 comments


None yet
2 participants
Copy link

jmcanterafonseca commented Nov 14, 2016

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.

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

What do you think?


This comment has been minimized.

Copy link

fgalan commented Nov 14, 2016

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.


This comment has been minimized.

Copy link

fgalan commented Nov 21, 2016

@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.


This comment has been minimized.

Copy link

fgalan commented Jun 14, 2018

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

CC: @jmcanterafonseca

@fgalan fgalan removed the APIv2 label Jun 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment