This project is read-only.

DateTime literal

Topics: C# Language Design
Apr 7, 2014 at 12:31 PM
It exists in VB, but not in C#. I have made a quick search on why and all I have found so far is "it's not in the specs". So, why the difference between the languages?
Apr 7, 2014 at 11:39 PM
I believe the presence of that in VB is a reminiscence of VB6.

How would you propose it to be implemented for C#? In what format?
Apr 8, 2014 at 7:42 AM
I believe strongly in international standards so I propose a "dual parsing"; support for the Invariant Culture date/time format (US English) and support for ISO 8601 (YYYY-MM-DDTHH:mm:ss.fffffTZD), with or without the T(ime) delimiter and with or without the time zone designator.

To be able to distinguish the date/time literal from a numrerical expression I arbitrarilly propose the @ sign (the # sign in C# should in my humble opinion be reserved for something far more important :-) ).
const ruleStartDate = @2014-04-27@;
const initialStartTime = @08:00:00PDT@;
Apr 8, 2014 at 7:58 AM
Edited Apr 8, 2014 at 7:58 AM
So with your beliefs, would that constants be DateTime or DateTimeOffsets?
Apr 8, 2014 at 8:05 AM
Edited Apr 8, 2014 at 8:05 AM
JanKucera wrote:
So with your beliefs, would that constants be DateTime or DateTimeOffsets?
When you're writing a numeric constant, the language will figure out for itself whether you're looking for an int (say, 5) or a double (5.6). You can always, of course, hint it to the more inclusive side through variable types or explicitly including the ".0". I don't see any reason why date literals would have to be any different:
  • if you include the offset, it's a DateTimeOffset
  • if you don't, it's a DateTime
  • if you declare a variable of type DateTimeOffset and set it to a DateTime literal
Apr 8, 2014 at 9:08 AM
JanKucera wrote:
So with your beliefs, would that constants be DateTime or DateTimeOffsets?
I would generically say DateTimeOffset: boxing to DateTime is trivial at compile time and you get a consistant type experience.

The reason for having delimiters around the date/time literal is simply:
var a = 2007-06-01;
is currently (and should still be) equal to:
int a = 2000;
whereas
var a = @2007-06-01@
cannot be inferred as anything but a date/time literal (thus not breaking existing code).
Apr 8, 2014 at 10:43 AM
To accommodate the different date/time types, instead of a special delimiter for each type, the compiler could cast strings to the desired type:
var dt = [DateTime]'2014-04-08';
var dto = [DateTimeOffset]'2014-04-08';
var ts = [TimeSpan]'1:30:00;
But I don't see that happening.