Hacker News Reader

Comment by jameshart | Hacker News Reader

> Frink has special syntax for date values. You can write # 2001-08-12 # to mean the date 2001-08-12

Frink? Frink?

This Visual Basic erasure can not stand. The #-delimited date literal syntax has been found all over the VB family: Visual Basic, VBA, VBScript, and it persists to this day in Visual Basic .NET.

Of course, being a VB syntax, it's completely cursed. You can put

    # 01/05/2023 #

in a VB file, and what date it represents will depend on what locale it's.. compiled? executed? evaluated? in? Maybe? Depending on which VB dialect you're in? Good luck. Some of those languages would also accept

   # 01/05/23 #

And they might even agree about what century it's in.

View on HN

The cursed aspect that you mention is a mighty fine argument for why the article should indeed choose Frink as the language to steal from.

https://frinklang.org/#DateTimeHandling

A VB date literal is and always has been locale-independent. Originally, they did make the mistake of making it always US-style, M/D/Y. VB.NET added more sane formats such as YYYY-MM-DD.

Now if you tried to convert a Date value to String at runtime, yeah, that would use the current locale. That was a constant source of bugs in VB6 apps running on non-US locales (including, famously, at least one Microsoft installer).

Are you sure? Maybe for Visual Basic proper, but I thought the VBA date literal basically followed Excel date parsing rules, so was localized depending on your office inatall.

Apparently I'm misremembering: https://www.engram9.info/excel-2007-vba-2/date-literals.html

Still, this violates the principle of least surprise for non-american developers, at least, so seems pretty on brand for VB.

> what date it represents will depend on what locale it's.. compiled? executed? evaluated?

oh VB. you were so close to perfection. never change.

We don't have to follow locale, we could just force ISO 8601 and there won't be any ambiguity.

Yeah, but this is Windows we're talking about. Even the SCHTASKS program (kind of like /usr/bin/at) takes a date which is locale sensitive, making it absolutely useless for scripting. Check out this answer to a question about how to use it: https://stackoverflow.com/a/18730884

The language doesn't have to care about $PLATFORM, if the spec says dates in source are ISO 8601 they're ISO 8601 or they're invalid.

I think the argument here is that VB is cursed because Windows is cursed; it inherited the bias toward cursedness. Of course other languages can choose to do better.

Or you could just use the standard '2001-08-12' with no special syntax needed and avoid the problem altogether. ISO-8601 or it's invalid. There's no reason to allow other formats or need other syntaxes when we have a 35 year old standard to use.

There’s a Java compiler plugin, manifold, that makes this type of syntax easy. There’s an example covering the date “literal” case…

https://github.com/manifold-systems/manifold/tree/master/man...

But is that December 8th or August 12?

>> Frink has special syntax for date values. You can write # 2001-08-12 # to mean the date 2001-08-12

> But is that December 8th or August 12?

I didn't even think YYYY-DD-MM is a possibility. Maybe I can grant 08/12/2022 is ambiguous and so is 08-12-2022 but can we please agree YYYY-MM-DD can't have variations?

The first rule of timestamps is, we agree on nothing!

Reverse-middle endian YYYY-DD-MM is used in Kazakh writing (https://en.m.wikipedia.org/wiki/Date_format_by_country )

Anyone who packs multiple values into a single string hates the world and possibly themselves.

Nowhere is it written that we must use the same field separator between the ambiguous fields. We could fix this problem by using the separators as type signifiers.

We could also stop using day <= 12 in our examples, which would also help a ton.

Reply on news.ycombinator.com