Runtime: Support for Time data type

[grahamehorner]

Please consider adding a new core data type of time to the CLR/CoreFx with support for time zone this data type would then be used to support database etc.

[Suchiman]

Like https://github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/DateTimeOffset.cs ?

[grahamehorner]

The framework should support a time data type; time on it own with a time zone without a date, lots/most databases support time data types, when these are read the framework holds them in DateTime which IMO is incorrect and leads to confusion/misinterpretations

[miloush]

@grahamehorner Since MSSQL does not have a time type with time zone support, it might help if you listed some of the databases and types you are thinking about.

[miloush]

@Suchiman note that DateTimeOffset stores time offset, not the time zone, which is an important difference.

[grahamehorner]

@miloush I didn't say databases store time zone information; I said time data types, big difference. IMO the framework should support a time data type with a time zone. when a time is read for the database the time zone would/could be UTC/known or set accordingly via the DAL; but it should IMO be supported by the framework and Time.Now would use the system culture to default the time zone.

[miloush]

@grahamehorner I didn't say that either. But I got lost a little bit now, you are asking for it in order to support databases, but now you are saying DAL would provide it and not the database? So are you looking for a type with offset (like DateTimeOffset but without date) or a type with an actual time zone associated?

[grahamehorner]

@miloush I'll try to explain a little better; most databases now support time data types; and I've had a lot of instances where I simply need to store a time with a piece of data (not interested in the date) when persisting to a store (database or otherwise) a time with a time zone would be good; however if the store (MSSQL) doesn't support a time data type or time with time zone; the DAL would need to handle that use case, possibly persisting the time zone information to a separate field.

using a time data type with a time zone also allows the UI to display the time accurately/removes user confusion when looking at a time which may have came from a user/system in a different time zone.

IMHO DateTime, Date, Time are three separate data types which have a common thread and may be chronologically ordered.

[miloush]

I would guess it might be a bit difficult to get people agree on how the time zones and DST should be handled, where they should come from and how they should change/be kept up to date and converted in between.

Using time offset might avoid those problems, but then the most logical thing for the DAL/database that does not support this would be to use DateTimeOffset and just ignore the date part...

[mikedn]

What exactly do you mean by a time with a time zone? A time zone is a GMT offset and a set of DST rules. To apply the DST rules you need to know the date so a time with a time zone seems like a rather odd construct. Perhaps you are looking for something like TimeSpan but restricted to 24 hours. Maybe you'll find the experimental System.Time library from corefxlab interesting.

[grahamehorner]

Time Zone see http://www.timeanddate.com/time/zones/ @mikedn yes, the System.Time in corefxlab is interesting; didn't know about this

[mikedn]

Time Zone see http://www.timeanddate.com/time/zones/

I know what a time zone is. What I don't understand is how a time and time zone could be useful without a date.

[svick]

Since this is an API addition, I think this issue belongs to corefx, see the API review process.

[scalablecory]

For great date/time support, I'd recommend using Noda Time. It captures the stuff that the built-in features don't.

[joperezr]

We would need to get a full API proposal in order to consider this.