user based timezone response

[OutdatedVersion]

Issue:
The system returns the time zone of the hosting server instead of the user

Reproduce:
1.

$ curl -L covid19.trackercli.com/us

It is currently 2:32pm where I am though receive this:

created as requested here

[OutdatedVersion]

Implementation wise, as this is done from HTTP tools we have just a small handful of information about our user.

So far, all I can think of is performing a reverse lookup on their IP address and then determine the locale of the country they're in. Zeit has a x-now-trace header which may be something we can leverage already built into the infrastructure. Outside of that there are many services such as ipinfo.io or ipify (may add onto operating cost :/).

[warengonzaga]

@OutdatedVersion I just closed #25 due to outdated code base. Please submit a new one... Thanks!

[gilcot]

Don't add complexity with third part additions, just ensure you keep worldometer's datetime: it's Zulu (GMT+0).

That datetime may be translated to user's locale if the information is available… ECMAScript has getTimezoneOffset() for that purpose.

Another thing to mention: use iso formating to be aware of cultural formating… In the screenshot, depending where you live, "4/1" may be january 4th or april 1st.

[OutdatedVersion]

@gilcot The issue is that we don't have that information. A HTTP request from cURL wouldn't have the user's locale. We could add a parameter for the preferred time zone, but I don't think it is totally unreasonable that it "just works".

[warengonzaga]

@OutdatedVersion thank you! As alternative I publish this project to NPM which is can be locally run and by that means the local version is using the local timezone of a user. However on our part since it runs on other server via vercel it uses the timezone on that server I guess I can convert it back to standard timezone for global reference since we can't fetch or get the timezone of every curl to the app.

[gilcot]

Don't forget @OutdatedVersion that one can add custom headers to cURL command, that's why I said it should be a translation performed only if the information is available. And otherwise just say what's the server's timezone…

[OutdatedVersion]

I understand, @gilcot. If support was added for a client directed locale, as mentioned in the last message, I think it would go better as a query parameter. Originally, it seemed optimal to the UX by having it simply "work" when making requests without that much hassle on our end - as it is already built into the infrastructure we use.

@warengonzaga, I don't think an installable CLI is the best path TBH. Too much friction to start using it. What are your thoughts on a query parameter? Typing ?timezone=cst is more intuitive than -H 'X-Timezone: cst' I believe.

[warengonzaga]

@OutdatedVersion good suggestion but I will consult my team if it is possible what we need for now is standard time. That's maybe the best bet.

[warengonzaga]

@scinscinscin is the fix already present in v4 branch? or not?

[warengonzaga]

This issue is now stagnant. I will work on it next week.