Skip to content
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

Define User timezone #927

Closed
wants to merge 2 commits into from
Closed

Conversation

@thiagocordeiro
Copy link

@thiagocordeiro thiagocordeiro commented Mar 31, 2017

this feature allow developers to define user timezone, when this is set, Carbon will apply given tz to the date before parsing into strings

this feature allow developers to define user timezone, when this is set, Carbon will apply given tz to the date before parsing into strings
@Glavic
Copy link
Collaborator

@Glavic Glavic commented Feb 16, 2018

This is really bad solution. You can see that in failing test. On other hand, people do not expect for format() method to change object timezone. Timezone should be changed on cloned object, not on calling one. Based on that, I don't see this being implemented, since it is too user specific. If you have any new feature, please don't hesitate to comment.

@Glavic Glavic closed this Feb 16, 2018
kylekatarnls added a commit to kylekatarnls/Carbon that referenced this pull request Apr 14, 2018
@kylekatarnls
Copy link
Collaborator

@kylekatarnls kylekatarnls commented Apr 14, 2018

Thanks, your code will be added as macro example:
gh-pages...kylekatarnls:gh-pages-1.26

@efraindx
Copy link

@efraindx efraindx commented Feb 17, 2019

Thank you very much @thiagocordeiro for your approach. I've implemented the function name in my local project of this way: setDestinationTimezone(), because I needed both things, convert times from application to users and from users to application. IMO this way is better because of that.

@kylekatarnls
Copy link
Collaborator

@kylekatarnls kylekatarnls commented Feb 18, 2019

I cannot be sure as I don't see your code, but I don't think your approach is right. You should not convert from user timezone to application timezone. The browser can send UTC dates (toISOString), and that's the only reliable data to send. And then, the server always receive UTC dates no matter from where it's sent. So you can reconvert it easily to anything with no risk of mistake (DST, timezone change, timezone bad detection). But it should not be needed at all as you can simply set your server timezone as UTC. And you should.

Here are some articles to explain deeply how to handle properly timezone front-side/back-side:
https://medium.com/@kylekatarnls/always-use-utc-dates-and-times-8a8200ca3164
https://medium.com/@kylekatarnls/handle-dates-the-right-way-in-php-c215650fc4fa

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.