# |
Jul 4th 2017, 15:24 |
birdy247 |
doesnt* |
# |
Jul 4th 2017, 15:24 |
birdy247 |
but that does work |
# |
Jul 4th 2017, 15:24 |
birdy247 |
Yea, I wanted to crate from format |
# |
Jul 4th 2017, 15:24 |
neon1024 |
Otherwise every time you run your test your Time::now() will be different |
# |
Jul 4th 2017, 15:24 |
neon1024 |
Fixtures should have fixed data |
# |
Jul 4th 2017, 15:24 |
birdy247 |
but doesnt like that :P |
# |
Jul 4th 2017, 15:24 |
birdy247 |
I tried 'closing_date' => Time::now(), |
# |
Jul 4th 2017, 15:23 |
birdy247 |
Can I make this a Time object? |
# |
Jul 4th 2017, 15:23 |
birdy247 |
the fixture is written like this: 'closing_date' => '2017-06-01 13:00:00' |
# |
Jul 4th 2017, 15:23 |
birdy247 |
Mainly interested in the date returning correctly |
# |
Jul 4th 2017, 15:22 |
birdy247 |
I am making a new test, and checking a simple find |
# |
Jul 4th 2017, 15:18 |
neon1024 |
Hah, well I’ve hit most snags once before, I tend to look out for them nowadays ;) |
# |
Jul 4th 2017, 14:48 |
birdy247 |
gd advice as usual neon1024 |
# |
Jul 4th 2017, 14:47 |
birdy247 |
:+1: |
# |
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 |