The Base Class Libraries is exploring scenarios related to Time Zone support and we are very likely to have a solution for this problem in the next release. We have already received a lot of great feedback from an earlier post. There are several high level scenarios where we have already received considerable feedback that they are in high demand and would be broadly used:
- Enumerating a set of time zones
- Converting between a set of time zones
- Serializing and de-serializing a time zone
- Having a DateTime with a UTC offset baked in.
- Supporting historical time zone conversions where the daylight savings rules can change from year to year.
A less clear question is about more secondary time zone scenarios. We really can’t have too much customer feedback about these to help us build the best feature possible. We would be interested in hearing feedback about these more secondary scenarios:
1. Creating a custom time zone, i.e. programmatically creating a time zone other than the default set of time zones on the machine.
2. Writing a custom time zone back permanently to the default set of time zones on the machine.
3. Creating a copy of a time zone with daylight saving time turned off.
4. Functions to ask whether a local time falls into an undefined or ambiguous/overlapped region caused by winding the clock back or forward for Daylight Savings Time boundaries.
5. Supporting historical time zones where the base offset can change from year to year.
6. Supporting changing the machine’s current time zone.
7. Supporting an ambient time zone setting at the level of the thread or process.
8. Helper functions allowing for some simple conversions to happen in a single line of code. e.g. TimeZone.Convert(time, “Pacific”, “Eastern”).
9. Parsing and formatting of DateTimes with embedded time zone acronyms, e.g. “PST”, “EDT”.
Another thing we would be interested in hearing about are TimeZone related scenarios that you feel are important but are not on either of these lists.
It should be made clear that we cannot necessarily provide all of these even if they are in high demand, as there are non-obvious technical difficulties with some of these, and we always have to balance demand for these against the opportunity cost of doing other BCL feature work. However, the more information we have about what people would actually need the better solution we can provide.
We would be open to information in any form, e.g. ranking the secondary scenarios in order, indicating a “yes/no/maybe” on whether the would be used by your, or calling out scenarios we should explicitly not be supporting for one reason or another. Detailed discussion of scenarios is also most welcome. Any feedback would be much appreciated and will help us deliver a better product.