I am trying to figure out how to create a new DateTime object in a different timezone. For instance, no matter where the code is run from, I want the new DateTime object to be October 26, 2007 3:11pm Mountain Standard Time. Can anyone help me out on this one?
New DateTime in a Different Timezone
- Thread starter dustydee
- Start date
Why not use the date-time coordination that is already there and used all over the world, Coordinated Universal Time (UTC) ? Date(time) have uses for this, so have TimeZone class.
By using one of the Date constructors. A DateTime is only a DateTime you know, and is the time zone you consider it to be. It's only when you relate it to other time zones you need to know what time zone you currently have and the offset to the other, here is where UTC come to play because all time zones have a defined relationship to this common time, for any time zone you can ask the TimeZone class to find its offset to UTC. It you ask computer for current time you can get it in local time or UTC time, for local time you can always relate it to UTC which can be compared with other UTCs from anywhere. That's how time zones work. UTC also mean we don't need to know everything about all places and timezones in the world, but only need to know our place (offset) in relation to Universal time in order to speak the same language.
About your question, if you say you have a UTC of October 26, 2007 3:11pm, I say good for you. That mean you have a DateTime object of value October 26, 2007 3:11pm that you consider to be time zone UTC.
About your question, if you say you have a UTC of October 26, 2007 3:11pm, I say good for you. That mean you have a DateTime object of value October 26, 2007 3:11pm that you consider to be time zone UTC.
DateTimes do have a UTC offset, but you cannot create a DateTime for a specific time zone. You can create a DateTime for the current time zone, which is the default, or you can create a DateTime for UTC, but a DateTime is just a representation of date and time. It's just like whether I specify '15' or 'XV', it's still just a representation of the number 15. They are just two different representations of the same thing.
If you want clients in different timezones to be able to coordinate on date and time then you should ALWAYS use UTC. When you create a DateTime value it will be local time by default. You can call its ToUniversalTime method to get the equivalent UTC value to save. When you retrieve that value into a client you can call its ToLocalTime method to get the local equivalent to display to the user. That way the times saved and loaded are always coordinated and correct, but each user only sees the values in terms of their own local time zone.
If you want clients in different timezones to be able to coordinate on date and time then you should ALWAYS use UTC. When you create a DateTime value it will be local time by default. You can call its ToUniversalTime method to get the equivalent UTC value to save. When you retrieve that value into a client you can call its ToLocalTime method to get the local equivalent to display to the user. That way the times saved and loaded are always coordinated and correct, but each user only sees the values in terms of their own local time zone.
That is true for .Net 2.0, but .Net 1.1 didn't have DateTimeKind. That also meant one could call ToUniversalTime many times and it would always convert the value one more time offset. With .Net 2.0 this can't be done since Date will lock to local or UTC and refuses to perform "stupid" operations.
Similar threads
- Question
