Static Methods for Dealing with Conversions from and to UTC
Using the String constant LOCAL_TIME_ZONE_STRING_REPRESENTATION, any user who wishes to compile the code can specify which time zone they want the code to run in, rather than it try to use Window's local time zone.


I think this is not the right way to provide flexibility. Lets say you sell your application to three different customers that want three different LOCAL_TIME_ZONE, then you'll have to compile the application three times. Do yourself the favor and place this as a setting in a configuration file or database. And what if the application is to be used world wide by a global customer? Do you plan to use the same time zone in all their offices?




    public static DateTime ConvertToUtcDateTime(DateTime dateAndTime)
    {
        return TimeZoneInfo.ConvertTime(dateAndTime, LOCAL_TIME_ZONE).ToUniversalTime();
    }



I don't think this is working correctly: 

A DateTime object can either represent a local time which is always regarded as  local according to the system settings or a UTC time if created with kind = DateTimeKind.Utc - seen from the DateTime api.

Let say LOCAL_TIME_ZONE_STRING_REPRESENTATION = "GMT Standard Time"; and the system time zone = "Romance Standard Time" (+01.00).

Because TimeZoneInfo.ConvertTime(dateAndTime, LOCAL_TIME_ZONE) converts from local time (Romance Standard Time), it converts 

DateTime inputDate = new DateTime(2019, 3, 1, 15, 30, 0);


to

01-03-2019 14:30:00


and the call to ToUniversalTime() converts it further to:

01-03-2019 13:30:00


because this too anticipate the DateTime object to be in local time, which is "Romance Standard Time" and not "GMT Standard Time". 

But if you - as you write in the explanation to the method - expect the input date time object to be in LOCAL_TIME_ZONE, no change should occur, because GMT = UTC.

To do it correctly I'll suggest this approach if the input DateTime object is still expected to be in LOCAL_TIME_ZONE:

public static DateTime ConvertToUtcDateTime(DateTime dateAndTime)
{
  return TimeZoneInfo.ConvertTimeToUtc(dateAndTime, LOCAL_TIME_ZONE);
}




That said, if I were you, I would reconsider the whole setup thoroughly before using it in a larger scale. Dates, Times and globalization in general is rather complicated, so do yourself the favor to read and test a lot before taking a concept into use that is not just relying on the system. A place to start reading could be here.