We Keep Coding

DateTime in a TimeZone which is not UTC or Local

I have question pertaining to the DateTimeKind struct in C#.
If I have converted a DateTime to a new DateTime (which is not in my local Timezone) using something like:
TimeZoneInfo.ConvertTimeBySystemTimeZoneId(now, "Tokyo Standard Time");
what should I use for the Kind property of that new DateTime? Unspecified feels a bit weird and does not help much with conversions.
I get the feeling that as soon as you use a Timezone which is not your local and not UTC, then you absolutely have to start using the DateTimeOffset struct.

This is more a question about how to handle non-local TimeZones.
When you go beyond your local timezone, you really do need to use the DateTimeOffset class.
When writing a time service, you may want to add a method for converting a DateTime in one non-local timezone to another non-local timezone. This is pretty straight forward when using the DateTimeOffset class:
public DateTimeOffset ConvertToZonedOffset(DateTimeOffset toConvert, string timeZoneId)
{
var universalTime = toConvert.ToUniversalTime(); // first bring it back to the common baseline (or standard)
var dateTimeOffset = TimeZoneInfo.ConvertTime(universalTime, TimeZoneInfo.FindSystemTimeZoneById(timeZoneId));
return dateTimeOffset;
}
The incoming DateTimeOffset has the source offset and the timeZoneId being passed in gives enough information to realize the target timezone (and offset).
And the returned DateTimeOffset has the target offset.
It gets a bit clunkier when you do it with the DateTime struct, if you wanted to provide an equivalent method:
public DateTime ConvertToZonedOffset(DateTime toConvert, string sourceTimeZoneId, string targetTimeZoneId)
{
return TimeZoneInfo.ConvertTimeBySystemTimeZoneId(toConvert, sourceTimeZoneId, targetTimeZoneId);
}
And this is where the DateTimeKind comes in. If you:
pass the DateTime in with the Kind set to either UTC or Local; AND
the sourceTimeZone is neither of those,
then ConvertTimeBySystemTimeZoneId will throw an exception. So, when you are dealing with a "3rd timezone", Kind must be Unspecified. This tells the method to ignore the system clock, to not assume that it is UTC and to go by whatever is passed in as the sourceTimeZone.
It's not as good as the DateTimeOffset version in another way. The returned DateTime has no information about the timezone and the Kind is set to Unspecified. This basically means that it is the responsibility of the calling code to know and track what timezone that date and time is valid in. Not ideal. So much so that I decided to "be opinionated" and get rid of that method. I'll force the calling code to convert the DateTime they may be working with to a DateTimeOffset and to consume one upon return.
Note 1: if Kind is set to Local and the sourceTimeZone matches your local timezone, it will work fine.
Note 2: if Kind is set to Utc and the sourceTimeZone is set to "Coordinated Universal Time", you may get the following TimeZoneNotFoundException:
The time zone ID 'Coordinated Universal Time' was not found on the local computer
I assume that this is because UTC is a standard and not a timezone, despite being returned by TimeZoneInfo.GetSystemTimeZones as a Timezone.

what should I use for the Kind property of that new DateTime? Unspecified feels a bit weird...
...but it's the correct value in this case. The documentation of the DateTimeKind enum is quite clear on this subject:
Local (2): The time represented is local time.
Unspecified (0): The time represented is not specified as either local time or Coordinated Universal Time (UTC).
Utc (1): The time represented is UTC.
Your time is neither local time nor UTC, so the only correct value is Unspecified.
I get the feeling that as soon as you use a Timezone which is not your local and not UTC, then you absolutely have to start using the DateTimeOffset struct.
You don't have to, but it can definitely make your life easier. As you have noticed, DateTime does not provide an option to store the time zone information along with the date. This is exactly what DateTimeOffset is for.

DateTime format usage in C#

I have following date time format
TimeZoneDetails.TimeZoneInstance ="Australia/Perth"
DateTime Today = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow,TimeZoneDetails.TimeZoneInstance);
Does today variable store the date based on timezone?
string date = "2020-03-19";
DateTime startdate = DateTime.Parse(date);
What is the timezone of startdate variable?
DateTime enddate = TimeZoneInfo.ConvertTimeToUtc(startdate, TimeZoneDetails.TimeZoneInstance);
Will enddate variable converted to UTC time?

A few things:
"Australia/Perth" is an IANA time zone identifier. It will work with .NET on Linux or Mac OSX, but on Windows you'd have to use "W. Australia Standard Time" instead. Alternatively, you could use my TimeZoneConverter library to work with either form of identifier on any platform.
In your code:
TimeZoneDetails.TimeZoneInstance ="Australia/Perth"
This isn't generally valid. Given the usage in the rest of your code, your TimeZoneInstance would have to be a TimeZoneInfo object. You can't assign a string in that way. You'd have to use a function like TimeZoneInfo.FindSystemTimeZoneById, or TZConvert.GetTimeZoneInfo from TimeZoneConverter, or a similar function in your own code. (Also you're missing a semicolon.)
In your code:
string date = "2020-03-19";
DateTime startdate = DateTime.Parse(date);
You asked what the time zone is in the startdate variable. That's a DateTime, which does not store time zone or offset information. It only has a .Kind property, which is of type DateTimeKind. In your example, it will be DateTimeKind.Unspecified. Also note the time will be set to 00:00:00.0000000.
You can read more about this in the documentation, here and here.
In your code:
DateTime enddate = TimeZoneInfo.ConvertTimeToUtc(startdate, TimeZoneDetails.TimeZoneInstance);
Yes, that will correctly convert the DateTime from the time zone given to UTC. Because startdate.Kind == DateTimeKind.Unspecified, the value is treated as belonging to the time zone specified. The resulting value will have enddate.Kind == DateTimeKind.Utc.
You can read more in the documentation, here.
In comments you asked:
which one is default for DateTimeKind?
That depends on which method you call to create the DateTime, and what values you pass in. In your case, because you call DateTime.Parse and pass a string that contains no time zone offset information, the resulting value has .Kind == DateTimeKind.Unspecified. You can read more about the behavior of DateTime.Parse in the remarks section here. Other methods and constructors behave similarly, but you should check the documentation for each, or validate the results yourself. You may find conversion errors if you, for example, think a DateTime has Unspecified kind, but it actually has Local kind due to how you obtain it.

What happens when we convert UTC Date time ToUniversalTime?

What happens when we convert UTC Date time ToUniversalTime?
DateTime localDate = DateTime.Now.AddMinute(offsetTimeZone);
DateTime todayStart = localDate.Date.ToUniversalTime().AddHours(00).AddMinutes(00);

There is a -lot- going on when converting using ToUniversalTime. DST is addressed, local time, etc. etc.
Just go to the reference source and read through the code:
http://referencesource.microsoft.com/#mscorlib/system/datetime.cs,fddce8be2da82dfc

There is already the same question on stackoverflow.
here is no implicit timezone attached to a DateTime object. If you run ToUniversalTime() on it, it uses the timezone of the context that the code is running in.
For example, if I create a DateTime from the epoch of 1/1/1970, it gives me the same DateTime object no matter where in the world I am.
If I run ToUniversalTime() on it when I'm running the code in Greenwich, then I get the same time. If I do it while I live in Vancouver, then I get an offset DateTime object of -8 hours.
This is why it's important to store time related information in your database as UTC times when you need to do any kind of date conversion or localization. Consider if your codebase got moved to a server facility in another timezone ;)
You can find the question and the complete answer here.

DateTime objects by default are typed as DateTimeKind.Local. On parsing a date and set it as DateTimeKind.Utc, then ToUniversalTime() performs no conversion. If we run ToUniversalTime(), it uses the timezone of the context that the code is running in.

Is it possible to set DateTimeOffset to a SAME offset for all the Silverlight clients?

I use DateTimeOffset for the date/time values.
And what I want to achieve is, for all the clients who load their page to run a SilverLight app., I want them to see the Dates according to a specific zone, for example Tokyo time.
So no conversion to their LocalTime will occur.
Is it possible to configure that for all the Silverlight clients they will see the DateTimeOffsets as for example, UTC + Offset of Tokyo ? Not as their local time?

This always returns Tokyo time
DateTimeOffset tokyoTime = DateTimeOffset.UtcNow.ToOffset(TimeSpan.FromHours(9));
For DateTime you can use this:
DateTime tokyoTime = TimeZoneInfo.ConvertTimeFromUtc(DateTime.UtcNow, TimeZoneInfo.FindSystemTimeZoneById("Tokyo Standard Time"));

I ran into a simliar problem, the solution I found was not to mark the date or DateTimeOffset property/fields as datamembers, but rather to create an additional string property that is the datamember and perform a string conversion in the getter/setter functions

C# UTC DateTime query in WCF/.NET

This is a very simple, (hopefully) question. I am new to working with DateTime conversion in .NET.
I have a WCF service which has a DateTime property - call it BookingDate.
Someone passes that to my WCF service in the format:
<a:BookingDate>2012-03-26T17:03:00-04:00</a:BookingDate>
The server that it is sitting on is set to a timezone of UTC (Lisbon, London, Dublin).
When I store the corresponding value in the database, it sets the value to be:
2012-03-26 22:03
I assumed, I think incorrectly that the .NET framework (as part of the WCF serialize/deserialize process) would pop this into a .Net Datetime of UTC for me (as there is the minus offset of 4 hours as above)
I was expecting: 2012-03-26 21:03
My question is thus: would I need to call:
var date = fromClientWCFService.BookingDate.ToUniversalTime();
in order to get the 21:03 time that I am expecting?
If not, is there a WCF setting to tell my service to convert DateTimes to UTC, rather than the server timezone?
Thanks in advance
Mark
EDIT:
From 1 answer, I can see that DateTimeOffset can be used. Following on from this, would the following work: var offset = DateTimeOffset.Parse("2012-03-26T17:03:00-0400"); to return the result: 2012-03-26 21:03

Instead of using the DateTime structure, you should use the DateTimeOffset structure.
The DateTimeOffset structure captures the offset from a specified time (it's not UTC by default, it's defined by the scope of your application, but the most common offset would be from UTC) along with the date/time information, and that information will flow through WCF calls (as well as to a database, assuming it supports the type. SQL Server in this case has the datetimeoffset data type from 2008 on).
As a matter of fact, using DateTimeOffset is the preferred methods of dealing with date/time data in almost all situations. Note from the previous link:
These uses for DateTimeOffset values are much more common than those
for DateTime values. As a result, DateTimeOffset should be considered
the default date and time type for application development.

If your server's timezone is on Lisbon/London/Dublin time, it is not UTC. You will either want to change the time zone of your server, or express the date/time value in UTC form when you update it in your database.