# |
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 :( |
# |
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 |