Format for date literals

[bclothier]

Closing this issue for now as the discussions around the potential formatting feature should be a separate issue.

Originally posted by @WaynePhillipsEA in https://github.com/WaynePhillipsEA/twinbasic/issues/17#issuecomment-865885286

From the twinbasic/twinbasic#17, there was a tangent discussion about the format for date literals which as per Wayne's suggestions, ought to be its own issue.

Problem

The VB* always formats the date literals in US format which is MM/DD/YYYY HH:NN:SS AMPM, which is potentially ambiguous. An unwary user could be caught out using #4/12/2021# and expecting December 4th, 2021, not April 12th, 2021. It also does not help the situations when we accept inputs from users on different Windows regions which can further complicate the programmer's life.

Proposed Solutions

In the linked issue, Wayne mused about the idea of using something more unambiguous like DD-MMM YYYY HH:NN:SS AMPM.... So we'd see 04-Dec 2021 which immediately removes the ambiguity over whether we start with days or months. The proposed format is indeed unambiguous but it is unfortunately also localized. A case has been made that because BASIC is already English-centric, there is no problem with using English names for months and weekday names.

I had proposed that we use date formats that is unambiguous and non-localized; two common formats comes to mind:

ODBC Canonical format: YYYY-MM-DD HH:NN:SS ISO 8601: YYYYMMDDTHHNNSSZ

I will admit I'm ahem opinionated on how date formats should be used, especially in programming, and from my experience working with databases, date data types is arguably the biggest PITA there is when doing with value data types. We still see questions such as "why doesn't my report show data on the last day when I run it for the week of 6/21/21?". What we naturally express is not always the same expression in a programming. When they ask for a report from 06/21/21 to 06/25/21, what we actually mean to do is something like >= #2021-06-21 00:00:00# AND < #2021-06-26 00:00:00#. It's questions like those that convinces me that a good programming language should strongly hint to the programmer the ideal date format that is will also work in other systems not just within BASIC.

To be absolutely clear, this is referring to how we should format our dates within code, not what we will display to the user, which could be MM/DD/YY or DD.MM.YYYY or whatever they want. The presentation of dates to the user is a completely separate issue from the representation of the dates, especially the literals, within the programming environment.

For those reasons, I'd love to see the YYYY-MM-DD HH:NN:SS format be made the format used for date literals.

[Kr00l]

If a date is constructed dynamically there is no issue as there is the DateSerial(). However, for date literals in ISO format is a workaround possible. To put it in a Const instead directly as literal. Example: Const D As Date = "2020-04-19 13:45:00"

Quote from Olaf:

Preprocessor is able to resolve also from Strings in ISO-format in a locale-independent manner, as long as the Const-Variable was explicitely typed as Date

Supporting date literals directly in ISO can cause incompatibilities? Maybe Wayne can comment on this.

[WaynePhillipsEA]

Let's put this to a vote.

If you would prefer twinBASIC to display date literals in the IDE using the YYYY-MM-DD HH:NN:SS format (e.g. 2021-03-01 12:00:00) please +1 this comment

[WaynePhillipsEA]

If you would prefer twinBASIC to display date literals in the IDE using the format DD-MMM-YYYY HH:NN:SS (e.g. 01-Mar-2021 12:00:00) please +1 this comment

[Kr00l]

To note is that format DD-MMM-YYYY HH:NN:SS would be source code compatible to VBx while the non-english format wouldn't. (Or not? Please confirm)

[WaynePhillipsEA]

@Kr00l, a quick check suggests VBx correctly understands and accepts both date literal formats correctly (checked with system regional formats of UK and USA).

My preference is still the DD-MMM-YYYY format as it means I don't have to think about the order since it's clear at a glance. We also have to consider that whilst we are programmers, many non-programmers start out with BASIC who would likely be unfamiliar with the YYYY-MM-DD format. If the vote goes in favour of the YYYY-MM-DD format, I'll add an on-hover tip that provides the DD-MMM-YYYY hint for clarity.

[mansellan]

I generally prefer ISO-8601 but @WaynePhillipsEA 's argument is compelling so I voted for the second option.

[bclothier]

To add to Wayne's answer to Kr00l's question:

One can indeed type in something like:

Dim d As Date
d = #2021-06-23#

and that will be understood and accepted by VBx* editor but it will then get prettified to d = twinbasic/twinbasic#6/23/2021#. Thus, it does no harm to the source code (for some value of "no harm").

However, full ISO 8601 compatibility is not possible as this would be a compile error:

d = #2021-06-23T00:00:00Z#

So we really can't use the ISO-8601 if we want the code to be readable by VBx. However, it has no trouble handling the ODBC canonical format as Wayne indicated earlier. We can certainly enhance tB to support parsing of ISO-8601 but that's yet another issue, I think.

[EduardoVB]

If we could go with a new, unknown and uncompatble format, I would suggest something very explicit like this:

Y:2021/[M|MO]:6/D:23/H:0/[N|MI]:0/S:0[/GMT:-3]

Where the order of the fields does not matter, since they have an identifier (mandatory). I've set as optional the time zone adjustment field, but even better if every field is optional.