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