The datetime will be converted to the logged-in users local timezone if you use apex:outputField to render your date.
You have to use apex:outputText if you don't want any conversion, which means it will be shown in GMT.
It seems you want to convert the datetime to the record creator's timezone for other users? I am not sure why you would want to do that, but if yes you will have to use Apex to get the timezone of the record creator and convert that before displaying to other users.
So, it sounds like you are trying to do the following:
- Retrieve a
String that represents time in PST timezone
- Convert that time to PST DateTime
- Find the GMT representation of the PST
DateTime
In order to convert the String that represents time in PST, you need to create a DateTime instance in GMT and then use the format() method to convert to PST.
Datetime pstDateTime = Datetime.valueOf(Datetime.newInstanceGMT(System.today(), <Time>).format('yyyy-MM-dd HH:mm:ss', 'PST'));
Once you have the pstDateTime, you can then create another instance of DateTime for GMT by manually constructing this instance using the pstDateTime attributes.
Datetime gmtDateTime = Datetime.newInstanceGMT(pstDateTime.year(), pstDateTime.month(), pstDateTime.day(), pstDateTime.hour(), pstDateTime.minute(), pstDateTime.second());
Using the code you have provided in your question and my code to resolve your issue, the following should work.
String timeStr = '15:00';
String defaultTime = '00:00';
String[] ct =
(timeStr != null) ?
timeStr.split(':') :
defaultTime.split(':');
Time t = Time.newInstance(Integer.valueOf(ct[0]), Integer.valueOf(ct[1]), 0, 0);
Datetime pstDateTime = Datetime.valueOf(Datetime.newInstanceGMT(System.today(), <Time>).format('yyyy-MM-dd HH:mm:ss', 'PST'));
Datetime gmtDateTime = Datetime.newInstanceGMT(pstDateTime.year(), pstDateTime.month(), pstDateTime.day(), pstDateTime.hour(), pstDateTime.minute(), pstDateTime.second());
Best Answer
The Time field type was created specifically to have a field that would be a time value independent of date. If your business hours are 08:00 - 18:00, regardless of the date, let's say, this is the purpose of this field. As the help states it is used "for time management, event planning, and project management."
For times that are time-zone dependent you can use the DateTime field instead. In that instance, you'll get a time that reflects the time zone of the user in accessing the field.
If you think about it, this makes sense. Without a date, it is impossible to be completely accurate about time zone conversion. Different parts of the world switch between summer and winter time. The ones that do, change at different times of the year. And some places do not change time during Winter and Summer.
Let's get concrete.
What is the time difference between London and New York? You might say 5 hours. And today 2 March, 2019, you would be correct. The UK is UTC +00:00, and New York is UTC -05:00.
But on 10 of March, the US moves to daylight saving time. The US will "Spring ahead" and New York will then move to UTC -04:00, but the UK (like most of the rest of Europe) will not change time. Meaning now there is a 4 hour difference between London and New York. Let me tell you, living in the UK, this wreaks havoc on my calendar as suddenly all my meetings with the US move an hour earlier. Argh!
For 3 weeks, just long enough to adjust, we remain in this strange 4 hour time difference temporary holding pattern until finally all us in Europe move to Summer time on 31 March. Havoc again ensues as we all go back to our regularly scheduled 5 hours difference with the UK moving to British Summer Time (UTC +01:00).
So a time field that exists independent of date would, by definition, be impossible to keep sync'd with time zones, until such time as the political will exists to end the silly time zone hopscotch that we're all subjected to. But that day is not today.