| # |
Jul 4th 2017, 14:47 |
 neon1024 |
Be interesting to discuss if I wasn’t silo’d |
| # |
Jul 4th 2017, 14:46 |
neon1024 |
I find if I try and pre-optimise I spend time in choice paralysis as I try and cover off all the use-cases, without any clue if they are relevant or not |
| # |
Jul 4th 2017, 14:46 |
neon1024 |
I guess you have to balance it with technical debt |
| # |
Jul 4th 2017, 14:44 |
neon1024 |
You’ll be writing code which will make maintenance harder for no reason |
| # |
Jul 4th 2017, 14:43 |
neon1024 |
I would advise against pre-optimisation |
| # |
Jul 4th 2017, 14:36 |
birdy247 |
but I am thinking longer term |
| # |
Jul 4th 2017, 14:36 |
birdy247 |
the TimezoneAwareDateTime will work |
| # |
Jul 4th 2017, 14:36 |
birdy247 |
for now, its only a London/Europe app, so its not a big issue |
| # |
Jul 4th 2017, 14:35 |
birdy247 |
Ill try and speak to jose_zap |
| # |
Jul 4th 2017, 14:24 |
neon1024 |
:coffee: |
| # |
Jul 4th 2017, 14:23 |
neon1024 |
Perhaps it was this ticket, https://github.com/cakephp/cakephp/pull/8588 |
| # |
Jul 4th 2017, 14:22 |
neon1024 |
Would make doing time maths more annoying though I’d imagine, as you’d end up doing lots of offset maths |
| # |
Jul 4th 2017, 14:22 |
neon1024 |
If that’s even a thing in mysql |
| # |
Jul 4th 2017, 14:21 |
neon1024 |
I suppose you could store the date time strings with an offset |
| # |
Jul 4th 2017, 14:21 |
neon1024 |
Might be better to talk to someone in a CEST timezone, as they’ll have way more experience |
| # |
Jul 4th 2017, 14:20 |
neon1024 |
Sorry, other than that, I’m out of ideas. |
| # |
Jul 4th 2017, 14:20 |
neon1024 |
Yes it’s identical |
| # |
Jul 4th 2017, 14:19 |
neon1024 |
Well you might be able to just make a beforeSave or something simple |
| # |
Jul 4th 2017, 14:19 |
birdy247 |
isnt this essentially the same thing? |
| # |
Jul 4th 2017, 14:19 |
neon1024 |
Jose said the same |
| # |
Jul 4th 2017, 14:19 |
neon1024 |
I just think the TimezoneAwareDateTime thing isn’t great code |
| # |
Jul 4th 2017, 14:19 |
neon1024 |
Then, https://book.cakephp.org/3.0/en/orm/database-basics.html#adding-custom-database-types |
| # |
Jul 4th 2017, 14:18 |
neon1024 |
https://book.cakephp.org/3.0/en/orm/saving-data.html#saving-complex-types |
| # |
Jul 4th 2017, 14:18 |
birdy247 |
behaviour? |
| # |
Jul 4th 2017, 14:18 |
birdy247 |
like what? |
| # |
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 :( |