Date data type in Typescript

Topics: Language Specification
Jun 19, 2013 at 2:22 PM
One of the things that has been been holding back my use of Javascript is the lack of serious support for the Date data type. The kinds of applications that I build (involving medical care) require extensive date-time manipulation capability. VBScript, for all of its other limitations, has a robust set of date validation functions (which are locale-independent) as well as numerous functions for date arithmetic - like DateDiff, DateAdd, etc.
There are a large variety of third-party libraries for date validation in JavaScript, but I don't know of any library that is both 100% robust as well as locale-indepenent (very often, they assume the US mm/dd/yy[yy] format. I'm sure it would not be difficult for the TypeScript team to take advantage of the work already done for VBScript and, after putting a simple wrapper around them, make them part of the TypeScript spec.
Jun 20, 2013 at 2:25 PM
I'm using moment.js which seems very robust, has all standrard date/time operations, and is localized in several languages. There's also a typescript defintion for moment.js at DefinitelyTyped
Jun 20, 2013 at 2:42 PM

Sugar.js adds a lot of useful Date functions, as well as Array, Object, etc. Also with DefinitelyTyped support.

Jun 20, 2013 at 4:02 PM

Thanks, went to the sugar site. However, when I experimented with the example on

http://sugarjs.com/dates

I found that when I entered 5-32-2013, I found that sugar accepted the bad input and assumed June 1. similarly 32-5-2013 (entered in the Canadian/British form) yields Aug 5, 2016. This is the same behavior as in JavaScript itself, but in real life these should be flagged as data entry errors, because they are likely to be typos or transpositions.

A further test: I changed my browser Language settings to UK (United Kingdom), where mm/dd/yyyy is used. Entering 23-5-2013 (which means 23rd May) yielded Nov 5, 2014. In other words, the Sugar date code does not sense locale.

VBScript, though limited in many ways, is smart enough to sense the Web browser locale and behave accordingly. If you are familiar with it, you can try the above, and then test for correctness using the Month( date-variable) function, which will return 5 if the setting of the browser is En-UK.

These issues are not theoretical. I maintain a Web-enabled clinical information system that supports multi-centric clinical trials, which is being used simultaneously by researchers in the US and Toronto, Canada (which follows the UK system of dates). I had to use VBScript and locale sensing simply because forcing Canadian users to enter dates in US format would be far too error-prone. VBScript is also smart enough, once it receives date data from a database (hosted in the US) to render dates on Web pages appropriately in a locale-aware manner. After all, when international users buy stuff on Amazon or E-Bay, or use other web pages, Amazon doesn't force them to enter date data in the US format, or in English.

The Amazon/Google developers spend significant effort localizing their Web pages. The whole idea of a framework that is supposed to help browser development is that it reduces the effort required to do so.

best regards,

Prakash


Jun 20, 2013 at 4:43 PM
TypeScript is not a framework though. It's purely a tool on top of JavaScript. If you want a language with a rich standard library, TypeScript isn't it. It is definitely BYOM (bring your own modules), just like JavaScript dev is. It's best to just find either a JavaScript library that works for you or write your own.

Andrew Gaspar


Jun 20, 2013 at 10:59 PM
Edited Jun 20, 2013 at 11:02 PM
Prakash_Nadkarni wrote:
Thanks, went to the sugar site. However, when I experimented with the example on http://sugarjs.com/dates I found that when I entered 5-32-2013, I found that sugar accepted the bad input and assumed June 1. similarly 32-5-2013 (entered in the Canadian/British form) yields Aug 5, 2016. This is the same behavior as in JavaScript itself, but in real life these should be flagged as data entry errors, because they are likely to be typos or transpositions.
Programming languages and convenience libraries don't accept bad input; your application accepts bad input.

If you want validation of Dates, you need to write validation of Dates. If you want locale-aware date parsing, you need to write locale-aware date parsing, although it's a far better idea not to ask people to enter dates in the hopelessly ambiguous ##/##/## format in the first place.

You can't expect your programming language to catch these things for you, and even if you're using one that does (like VBScript), you don't just say "here's a thing that might be a date, or not, I haven't bothered to check it" and see if it throws an exception.
Jun 21, 2013 at 4:06 PM

Andrew,

Thanks for your note. I agree that because Typescript merely generates javascript, so it's handcuffed, in a sense, by what Javascript itself supports. However, there have been other language frameworks - the earliest version of the C++ compiler developed by Bjarne Stroustrup and his team at Bell Labs, which generated C code rather than native code, springs to mind - where the framework provided an extremely rich type system that the target language did not.

The whole idea of frameworks is supposed to be that 1) they save you programming effort 2) the resulting code is more robust / less error-prone. Given that dates are important in a variety of applications, I'm surprised that TypeScript does not include a standard set of date manipulation functions as well, which includes the best ideas from the various open-source JavaScript date-manipulation toolkits.

Mark,

>>>If you want validation of Dates, you need to write validation of Dates. If you want locale-aware date parsing, you need to write locale-aware date parsing, although it's a far better idea not to ask people to enter dates in the hopelessly ambiguous ##/##/## format in the first place.

We also support a study on tropical Leishmaniasis where field data is being gathered in Colombia (which uses Spanish) with the patient samples being processed for special tests at Yale (where English is used). The forms are localized through metadata - question captions, headings, etc. have both English and Spanish equivalents, so the form is rendered dynamically based on the browser's preferred language settings (nothing fancy - Google and Amazon also do this).

Your suggestion to use something other than the "hopelessly ambiguous" ##/##/## is not workable: it may be ambiguous to a programmer, but not to the (non-programmer) end-users within a single geographical location who use this format every day of their lives without being confused, and have no idea of the issues of software localization and couldn't even begin to define the term (and shouldn't be bothered about what is a programmer's issue).

In any case, if you're suggesting something like Jan-23-2013, our code accepts user input in ##/##/##(##) format and then echoes it back in MMM-nn-nnnn format as confirmation. The issue again is that in Spanish, January is Enero, and the three-letter abbreviation is different. Again, VBScript on the browser renders the correct
MMM-nn-nnnn format without any effort on our part - we don't store month long names or abbreviations in our browser code, because we don't need to.

VBScript uses a rich internal library to do what it does - including sensing of localization information from the client machine. In our code, I end up defining date-validation/presentation functions in VBScript and calling them in JavaScript (at the cost, of course, of cross-browser compatibility).

The point I'm trying to make is that the developers of VBScript at Microsoft did *something* right (though they did many other things wrong), and I'd hate to see the good part of their effort lost.

>>> I'm starting to wonder if you might have written some of the code I've reviewed recently...

I don't quite know what you're referring to here - I haven't put any code out that's related to this issue - but if this is an attempt at personal invective, it is both inappropriate in this forum and not very effective. One can agree to disagree without stooping to the level of ad hominem abuse.

Jun 21, 2013 at 5:02 PM

I apologise for the last comment, I actually deleted it on the forum but I guess you got the email version.

VBScript did altogether too much developer hand-holding, and produced a generation of developers ill-equipped to write quality applications without it. I maintain that handling local date formats is the responsibility of the application, or, at a stretch, a UI framework.

It surely isn't that much effort to write a scrap of JavaScript that will take a string and parse the date correctly.

My recommendation would be to have year, month, day fields and construct the date from those three values, or to provide a nice calendar popup or some similar control for entering dates.

Regardless of all that, the fact remains that TypeScript is in no way the successor to VBScript; it is a compiler providing a thin layer over JavaScript, and as such comes with no runtime libraries, one of which would obviously be necessary to add functionality such as you propose.

Dec 8, 2014 at 9:35 AM
Hi Prakesh,

I agree with you that there is something lacking in JavaScript when it comes to dates.

Here's a good way of passing the locale to the client in order to parse the date using the right format.

http://stackoverflow.com/a/674570/4504

Just spit back the Accept-Language header or convert it to a JavaScript flag called isDDMMFormat based on the date format for that locale.

Then you just have to split the string and parse it:
var isDDMMFormat = false; // This is generated on the server based on the Accept-Language HTTP header.
var year = input.substring(6);
var firstNumber = input.substring(2, 0);
var secondNumber = input.substring(5, 3);
var month = isDDMMFormat ? secondNumber : firstNumber;
var day = isDDMMFormat ? firstNumber : secondNumber;
var date = new Date(year, month - 1, day);