Database data source

[amandiobm]

#32

[jamesmills]

If the Trait is not added to the User model then how will it be able to call getTimezone()?

[nyalex]

So if we have a special data source of timezone are you suggesting that we extend the trait to pull it in?

[amandiobm]

@jamesmills Yep, I was thinking about that too. I think this feature has to be added as a new version. since it might bring break change. Since that trait, it will be mandatory.

@nyalex If this became a new version, you have to update your composer to pull this new version, and add this trait into the resource model, which usually is the User model, and if need it you can override those methods, to better suite your need.

[amandiobm]

Did some changes. Implementation still the same, but I tried to be more clear on the installation.

[jamesmills]

Love this conversation. Thanks all for contributing.

I’m confused why this would be a breaking change. The Trait would allow the developer to override the default column name or model where the timezone is set. That’s great. But if the Trait was not on the User model then.... ahhhhhhh hang on.... I was just about to say we can use a default method but we cannot because the package doesn’t have this.

Ok, so.

Option 1.
Can we add this as a config option instead? Have the default config set to Users::timezone and then you could publish this and override it to UserSettings::custom_timezone

Option 2.
We make a version 2. We force the Trait to be added to the User. Call it HasTimezone. We then add the option to override the location of the users timezone setting and we could then even override the format for each user. So say the user had asked to view all dates/times in format X then this could be stored in the user database table and you could override this using the Trait too.

Thoughts?

[amandiobm]

@jamesmills I prefer the 2 option ;)

[edgrosvenor]

@jamesmills I agree that option 2 is better. I'm currently working on a project where I have 3 different user models, none of which are App\User and I'm doing an extra round trip on several pages, getting the timezone from the browser, and using that to adjust for local time. This would be a better way to go because it would eliminate that extra round trip, but it would need to be a trait so I can apply it to each model and store the data in a way that makes sense for me.

[shivvani-patel]

I also having same problem.I am not using users table to store users data so in that case i need some configuration to set users table name and field column name or external command to get timezone.

[jamesmills]

I'm guessing that we can just add a HasTimezone as an option. So you can use the package each way without us having to talk about version 1 and 2.

[jamesmills]

actually been thinking about this a little more. I think we should continue with the config options for everything that people can customize. Then we add the ability to optionally add the HasTimezone trait to whatever Model you are using for your User. We then add to the README that the preferred way to use the package is to add the HasTimezone trait to your users model and give examples of how you can override things.

Could we then not include the Cast into the Trait? https://github.com/jamesmills/laravel-timezone/pull/35/files So that you don't have to manually add the cast yourself as it would be added by the Trait if you decide to use the Trait?

So the recommended way to use the package is to use the Trait on your User Model/Models. Then you get the ability to override where you get the timezone from and you automatically get the casting.

Gah!

[jelib3an]

Hi, just curious if anyone has tried making custom accessor and mutator on the model (getTimezoneAttribute() and setTimezoneAttribute(). If that works, then we would not need a trait?

[nonoesp]

Hi, all! 👋🏻

First of all, thanks for the package. =)

I browsed through the issues and found this pull request, as it seemed odd for my use-case to have to run migrations and rely on the database to store the current user's timezone.

I only need to guess the user's timezone (maybe keep it in the session if it's too expensive to repeatedly get it), but I have no need for the user to keep or modify settings throughout sessions.

Would the Trait or Accessor serve for this?

I'm trying to wrap my head around the current state of this package, as it seems there's a super-simple use-case for this package which doesn't require the use of migrations, database, user model, and flash messages.

Anyway, thanks again for open-sourcing this and for the time put to develop this piece of software.

Best!

Nono