feature request: datetime support

[ghostsquad]

Curious if anyone would find it useful to add dates & durations as a type or to add functions to create/parse/manipulate dates?

[sbarzowski]

Yes, that would be pretty cool. It's a bit tricky, though. The datetime is actually a pretty messy thing. You have surely seen an article like that: https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time.

So, we would need to figure out the core assumptions. For example we should probably use "proleptic Gregorian" from ISO 8601 like in Python. It's the calendar we usually use, with its rules extended in both directions indefinitely. Not everyone does it this way, though. Qt4 actually did the switching between Julian and Gregorian on the official date of the switch (which is a totally unnecessary complication and it's even crazier when your realize that some countries, e.g. Russia switched on different dates). Fortunately for Qt project, they switched to using proleptic by default in Qt5.

Timezones are the most tricky part and I'm not entirely certain we should support them at all. The problem is that they are not fixed, so we would need the user to pass that information explicitly (to avoid dependence on the environment). This may be reasonable for a limited number of timezones they care about, if they can't live with just the numeric offsets...

Also leap seconds. I think we should just assume that they don't exist.

Probably we shouldn't try to do all of that at once. E.g. converting from objective time to calendar time is waaay trickier than just implementing proleptic calendar, without support for time with some arithmetic on days.

[ghostsquad]

I was thinking more along the lines of some stdlib functions that could be called that farm out to time pkg in go...

[ghostsquad]

Oh I see, dates introduce non determinism to the output

[brianbraunstein]

What about just doing the duration part of this. Then all the ugly calendar stuff doesn't come into play right? I'm currently having a discussion about whether to use (in golang) a float64 or a time.Duration as a field that gets parsed by yaml.Unmarshal. The problem is that a lot of configs already exist where the fields have suffixes, so you can't easily do math on these in jsonnet.

Having just something like std.parseDurationAsSeconds that delegates straight to golang time.ParseDuration would be a huge win.

We're not using jsonnet yet but I'm hoping to convince people, this would definitely reduce one of the hurdles.