Log message #4047693

# At Username Text
# 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
# Jul 4th 2017, 14:10 neon1024 I would have everything in UTC, and only convert to the users timezone on display
# Jul 4th 2017, 14:10 neon1024 I’d spend hours debugging something to realise it’s a UTC not BST or something like that
# Jul 4th 2017, 14:10 neon1024 It feels like something which would trip me up later on during maintenance
# Jul 4th 2017, 14:10 neon1024 I mean having values with different timezones in different layers of your application
# Jul 4th 2017, 14:09 birdy247 how do you mean?
# Jul 4th 2017, 14:09 neon1024 I would be wary about mixing timezones in different layers of your application
# Jul 4th 2017, 14:08 birdy247 cant*
# Jul 4th 2017, 14:08 birdy247 :(
# Jul 4th 2017, 14:08 birdy247 I can get the request :slightly_smiling_face:
# Jul 4th 2017, 14:08 neon1024 Depends on what value is passed to the data type class I suppose, you’d need to check
# Jul 4th 2017, 14:07 neon1024 Not sure actually. If you can get the request you can get the session. My gut feeling is, no, as I don’t see why a data type class would need a request
# Jul 4th 2017, 14:06 birdy247 could I get this from the session in the TimezoneAwareDateTime
# Jul 4th 2017, 14:06 birdy247 as part of the users record
# Jul 4th 2017, 14:06 birdy247 neon1024 lets say we store the usersTimezone in the DB
# Jul 4th 2017, 13:58 birdy247 I think this was pre Chornos and all that milarky
# Jul 4th 2017, 13:57 birdy247 I have also had to change the TimezoneAwareDateTime
# Jul 4th 2017, 13:57 birdy247 :slightly_smiling_face:
# Jul 4th 2017, 13:47 neon1024 I mean, yes, of course it does
# Jul 4th 2017, 13:46 neon1024 Er
# Jul 4th 2017, 13:46 neon1024 Really?!
# Jul 4th 2017, 13:46 birdy247 Your approach works neon
# Jul 4th 2017, 13:42 birdy247 But thought I would try and get it working with the cake Form->control
# Jul 4th 2017, 13:41 birdy247 and just use the i18nFormat to display it correctly
# Jul 4th 2017, 13:41 birdy247 in other projects I use a JS datetime picker
# Jul 4th 2017, 13:40 birdy247 so use the createdUTC as the value for my "date" input
# Jul 4th 2017, 13:39 neon1024 I have pretty limited experience of it, being in the UK ;)
# Jul 4th 2017, 13:39 neon1024 I preferred the data type class, as it meant I was always working in the front-end timezone
# Jul 4th 2017, 13:38 neon1024 Then you could just have $entity->get(‘createdUTC’) or something, which just changed the timezone and returned a new date time instance
# Jul 4th 2017, 13:38 neon1024 I mean the easiest thing would be to creating an entity virtual field I suppose
# Jul 4th 2017, 13:38 birdy247 thats what I am using neon1024 :slightly_smiling_face:
# Jul 4th 2017, 13:37 neon1024 There was a whole bunch of discussion about how to translate between a backend timezone and a front-end timezone. Ionas linked me to the issue ages ago, but I don’t recall what it was called to search for it, or what the upshot was.
# Jul 4th 2017, 13:37 neon1024 I still use Josés old TimezoneAwareDateTime data type class :slightly_smiling_face: