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