| # |
Jul 4th 2017, 14:18 |
 neon1024 |
Or make something better ;) |
| # |
Jul 4th 2017, 14:17 |
birdy247 |
and it should all work |
| # |
Jul 4th 2017, 14:17 |
neon1024 |
It’s all about the data type layer in CakePHP |
| # |
Jul 4th 2017, 14:17 |
birdy247 |
All I need to do is figure out how to make the "SOURCE" dynamic in that |
| # |
Jul 4th 2017, 14:17 |
neon1024 |
The timezone data type handles the conversion of user input data into UTC |
| # |
Jul 4th 2017, 14:17 |
birdy247 |
Its use case 1 I seem to go around in circles in |
| # |
Jul 4th 2017, 14:17 |
birdy247 |
just throw in the users timezone and UTC will display in their timezone |
| # |
Jul 4th 2017, 14:16 |
birdy247 |
thats easy |
| # |
Jul 4th 2017, 14:16 |
birdy247 |
2) is taken care of with i18nFormat |
| # |
Jul 4th 2017, 14:16 |
neon1024 |
2) Displaying UTC date times in a specific timezone |
| # |
Jul 4th 2017, 14:16 |
neon1024 |
1) Collecting data input from a user in a specified timezone and saving it as UTC |
| # |
Jul 4th 2017, 14:16 |
neon1024 |
You have two use-cases to solve. |
| # |
Jul 4th 2017, 14:15 |
birdy247 |
Do it in the entity instead? |
| # |
Jul 4th 2017, 14:15 |
neon1024 |
It’s pointing you in a direction which is contradictory to the use-case you’re trying to solve in my opinion |
| # |
Jul 4th 2017, 14:15 |
neon1024 |
You should delete the timezone aware class, it’s not helping you |
| # |
Jul 4th 2017, 14:15 |
neon1024 |
Sorry, but I can’t think of a better way to explain it :( |
| # |
Jul 4th 2017, 14:15 |
birdy247 |
so how would I make it more "dynamic" |
| # |
Jul 4th 2017, 14:14 |
neon1024 |
No it isn’t |
| # |
Jul 4th 2017, 14:14 |
birdy247 |
Thats the sticking point |
| # |
Jul 4th 2017, 14:14 |
neon1024 |
Hence why it’s a constant |
| # |
Jul 4th 2017, 14:14 |
neon1024 |
In my project I only had GMT |
| # |
Jul 4th 2017, 14:14 |
birdy247 |
Neither do I |
| # |
Jul 4th 2017, 14:14 |
neon1024 |
I don’t change it on the way out |
| # |
Jul 4th 2017, 14:14 |
birdy247 |
How do you know their source timezone? |
| # |
Jul 4th 2017, 14:13 |
neon1024 |
Yes, to convert inputted data into UTC |
| # |
Jul 4th 2017, 14:13 |
birdy247 |
? |
| # |
Jul 4th 2017, 14:13 |
birdy247 |
and you use the TimezoneAwareDateTime |
| # |
Jul 4th 2017, 14:13 |
neon1024 |
The user enters date times in their own timezone, and you save it as UTC |
| # |
Jul 4th 2017, 14:13 |
birdy247 |
So everyone has to enter in UTC? or the "Source" timezone? |
| # |
Jul 4th 2017, 14:12 |
neon1024 |
I only really used the datetime class in my CMS |
| # |
Jul 4th 2017, 14:12 |
neon1024 |
Which is why I restricted my timezone conversion to being on display |
| # |
Jul 4th 2017, 14:12 |
birdy247 |
just the source |
| # |
Jul 4th 2017, 14:12 |
birdy247 |
the target constant is fine |
| # |
Jul 4th 2017, 14:12 |
birdy247 |
the TimezoneAwareDateTime is good, but works on constants |
| # |
Jul 4th 2017, 14:12 |
neon1024 |
Then if you communicate that datetime from US Guy to UK Gal, she can see it in her own timezone |
| # |
Jul 4th 2017, 14:11 |
neon1024 |
Yes |
| # |
Jul 4th 2017, 14:11 |
birdy247 |
so if user A is the America, whatever he enteres is stored in UTC similar to if User B if from london |
| # |
Jul 4th 2017, 14:11 |
neon1024 |
Well, I say, I would, that’s what I did with the timezone sensitive project I built |
| # |
Jul 4th 2017, 14:11 |
birdy247 |
from a dynamic input timezone |
| # |
Jul 4th 2017, 14:11 |
neon1024 |
Keeping the timezone manipulation in the front-end only |
| # |
Jul 4th 2017, 14:11 |
birdy247 |
I simply want a scalable way of setting all datetimes to UTC |