Below is my small test script. The parseDateTime function according to the documentation should not convert the datetime object to the timezone of the server if I use “standard”. But nothing I have tried keeps the conversion from happening.
Hi!
I can’t really follow up. Type “POP” is for converting a string as of the mailing/messaging protocol format , such as “Thu, 20 Feb 2020 01:27:43 -0400”. Your string text is not like that and in adobes CF it should throw an error because it doesn’t recognize your string. But Lucee does its best and tries to parse it anyway. It creates the time object.
But what parseDateTime does is: it simply creates a datetime object and when it is done there is no conversion to a servers time zone. It just parses the time as specified by you. If you have any time offset information in your string, pass that information in the format mask of the parseDateTime() function. See ParseDateTime() :: Lucee Documentation
Yes it does convert the date string into a datetime object but in the local time zone of the server. There is no way to keep the datetime object in the timezone that it was originally. There is also no way to extract a timezone from a datetime object. In the example below there is no way to know the date was UTC without parsing the text manually.
Edit: Andrews blog article and its referenced Video of Michael is really, really great and helpful. Just to be sure @Zackster: Does that mean that when having a internationalized multi-domain-website, best practice would be to save the datetime object always parsed/converted as UTC into a DB. Then for the output I would retrieve these UTC DateObjects, parse it to the refering domains timezone and output to a string with the respective locale, right?
Great video. Ok, I get what is happening but I still have this question. How do I get the timezone of a datetime string ‘2020-02-11 01:40:00 -0500’ via a CFML function? If I parse that datetime string I will end up with a datetime object for the timezone of my server. But I want to display the date & time to the user in the timezone where the object originated. In this case anywhere other than the timezone of my server.
<cfscript>
text = '2020-02-11 01:40:00 +0100';
dump( text );
zulu = parseDateTime( text, "standard" );
dump( zulu );
local = dateTimeFormat( zulu, "yyyy-mm-dd HH:nn:ss z" );
dump( local );
dump( dateTimeFormat( zulu, "yyyy-mm-dd HH:nn:ss z", "UTC" ) );
dump( dateTimeFormat( zulu, "yyyy-mm-dd HH:nn:ss z", "PST" ) );
dump( dateTimeFormat( zulu, "yyyy-mm-dd HH:nn:ss z", "EST" ) );
dump( dateTimeFormat( zulu, "yyyy-mm-dd HH:nn:ss z", "EDT" ) );
// dump( dateTimeFormat( zulu, "yyyy-mm-dd HH:nn:ss z", "+0100" ) );
// this last line throws an error.
// How to get back to displaying +0100 once the date is an object?
</cfscript>
I still didn’t try that, but I would store datetime as utc in one field and the timeoffset in another field, in your example, assuming that “2020-02-11 01:40:00” is UTC that would be something in the DB table like:
createdDateTime_UTC=‘2020-02-11 01:40:00’ and timeoffset_creator=‘-0500’
Then you’ll have the one and exact Coordinated Universal Time (UTC) stored, and you can translate it to any timezone you want, simply by getting the places timeoffset and add it to the UTC. That would be the dateobject in that time zone, but not the specific typical datetime-format output of the country used by its people and culture. South American and North American Countries have lots of same timezones, but still people in each country have cultural differences in wirting dates/times.That is where lsdateformat comes into play: it doesn’t change any datetime data, it only displays it differently.
Ex. DateTimeObject 2020-02-20 14:20 shows something with locale en_Us like 02/20/2020 2:20 PM while locale de_DE would be something like 20.02.2020 14:20. As you can see, the dateobject value is not changed, only the display format will be shown in the typical format of country and culture.
