It's 2 inconvenient characters longer for each one, but aliasing your date and time parsers to "d" and "t" and then adding parentheses to what you have written there seems like a good enough solution for the majority of cases.

Do you have so many time literals in your code?

Different literal types are only necessary when the parser needs to treat the string differently - that's why you need them for raw strings for instance.

When you don't need to do that, a function call is a much better answer. There are many things that could be string literals but aren't because they don't have to be.

Of you just go with pure ISO8601 then you won't need to differentiate between dates, times, durations and intervals; they can each be specified unambiguously. Up to you, of course; it might not make sense in your use-case.

That would be part of the plan.

My use case is the iPython astrophysicist use case, where users tend to be very interactive with their dates and times. In fact, that's why I made the query language, because it was necessary for dataset discovery (i.e. return datasets between this time and that time). Of course, we often use a variety of types of times, from Julian day to Mission Event Time (where an arbitrary epoch is chosen that's usually close to some significant event, usually full funding, mission launch, first light, etc..)

Of course we could always just use function calls, but the ability to have literals is really nice.

Maybe I'm just a dreamer, but a similar extension to javascript and JSON would be really nice as well, given that you need a schema to understand the proper parsing of dates, otherwise you end up with a string, number, additional type field, or a fallback to Hungarian notation.