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

Define User timezone #927

wants to merge 2 commits into from

Conversation

thiagocordeiro
Copy link

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 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 kylekatarnls added the macro candidate Rather than new methods, this could be a macro/mixin label Feb 17, 2018
kylekatarnls added a commit to kylekatarnls/Carbon that referenced this pull request Apr 14, 2018
@kylekatarnls
Copy link
Collaborator

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

@kylekatarnls kylekatarnls added documentation Rely to documentations or gh-pages branch and removed macro candidate Rather than new methods, this could be a macro/mixin labels Apr 14, 2018
@efraindx
Copy link

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

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
Labels
documentation Rely to documentations or gh-pages branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants