Req11: International date literals

[This post is part of a series, "wish-list for future versions of VB"]


IDEA: Allow date literals in a subset of ISO8601 format, e.g. #2010-01-26# or #2010-01-26T21:16Z#. (Currently VB only allows the US-specific form #MM/dd/yyyy#). Pretty-listing would leave dates in the format in which they were entered.

SCENARIO: You’re a developer outside the US reading some code. You don’t know if #1/2/2010# means January 2nd or February 1st.


Those of us on the VB team who weren’t raised in the US also get confused by VB date literals. We completely understand the wish for a better format.
On the other hand, we believe there aren’t many cases where you would want to hard-code dates into an application. Therefore we think the appeal of this feature would be too small to justify it.


Provisional evaluation from VB team: A nice in theory, but it's too rare to be worth changing the language for this. (TimeSpan literals would be more useful, but it's fine just calling the TimeSpan constructor).

Comments (10)

  1. Jonathan Allen says:

    Timespan literals would be very, very helpful for constants and optional parameters.

    What I thinkwe really need is a generalized way to define literals for value types for use in constants and optional parameters.

  2. Dzonny says:

    I’d really more appretiate TimeSpan literals than change in DateTime literals. Hardcoding dates into program is IMO more rare than hardcoding of times – and there’s no confusion about TimeSpan formating internationally.

    IMO ISO format is not less confusing than US one. Is it YYYY-dd-MM or YYYY-MM-dd?

    (Somebody from Czech Republic – native date format d.M. YYYY H:mm:ss)

  3. MarkJ says:

    Yes please, we have good reasons to have a few hardcoded dates in our programs, and this is a pain.

  4. Tim says:

    @Đonny: The ISO format is definately less confusing, since all standard time formats that start with the year and use "-" as seperators iterate from the largest to the lowest value. (yyyy-MM-dd HH:mm:ss) It is the only time format that really is obvious.

  5. Kevin Ryall says:

    This is a persistent annoyance for us non-US programmers (although to be fair, VB is far from alone in assuming that the US locale is the only one that counts). I don’t want to use our European date format either – if we could use an ambiguous format like ISO 8601 that would be perfect.

    While I very rarely have embedded date literals in production code, I have them very frequently in test code – and it’s a real pain to have to use US date formats (timespan constructors aren’t as readable as native date literals would be).

  6. Héctor says:

    Also found this to be a pain in the past, however, I agree that it is not a common scenario, so it should be considered, but as a low priority.

  7. Kyralessa says:

    I like the idea OK.  What about autocorrecting "old format" dates into "new format" ones?  So if you put in #5/4/2008# (in the US), when you moved off the line it would correct to #2008-05-04#.

    I agree with those who say it’s not a huge priority, though; obviously with the DateTime class there’s already a way to do this sort of thing.

  8. Richard says:

    I too think there should be a single format (namely ISO’s #yyyy-mm-dd#) to which old-style dates should be auto-corrected.

  9. Krzysztof Maczyński says:

    Months in the middle. The US format isn’t naturally sortable. That results in perceived weirdness by others.

    Wasn’t VB up to 6 more liberal about what you pot between the #s?

  10. Jer0enH says:

    I disagree that this is only rarely used. Of course you don't use hard-coded dates in most production code, but as others have said it's quite common in test code!

Skip to main content