Milliseconds ↔ xs:dayTimeDuration, Unix time ↔ xs:dateTime

[ChristianGruen]

Milliseconds ↔ xs:dayTimeDuration, Unix time ↔ xs:dateTime

[michaelhkay]

An alternative approach would be to have a function fn:seconds that returns an xs:dayTimeDuration of a given length, and perhaps a function fn:unix-epoch() that returns the relevant dateTime value, and then you can use these as constants to perform the relevant arithmetic, for example unix-epoch() + $timestamp * seconds(0.001). It also enables you to convert an xs:dayTimeDuration to decimal seconds by doing $dTD div seconds(1). (Perhaps s/unix/posix/)

[michaelhkay]

While conversion to/from Unix dates and times might be very handy for many users, it's not the only way of representing a date/time as an integer, so I think it should be a much more specific function saying exactly what it does, rather than an overload of the constructor.

If the reason for manipulating the value as a number is for ease of doing calculations, then Julian dates are surely more useful outside the field of Unix computing: they have a higher range and a higher precision.

And if we support Unix datetimes, what about .NET ticks? Some neutrality is called for.

[ChristianGruen]

That’s helpful, thanks. My proposal was mostly driven by user feedback, but I agree it would be reasonable to strive for a more generic approach.

[ChristianGruen]

Now that we have fn:seconds, should we also add fn:unix-time? Copied from #984 (review):

[…] we should add an alternative solution for xs:dateTime('1970-01-01T00:00:00Z'). It’s particularly tricky because of the timestamp syntax, and people may be tempted to write things like…

xs:dateTime('1970-01-01T00:00:00') + seconds( (: input from 'date +%s' or similar :) )

…which gives a similar, but wrong result. fn:unix-time() would be my favorite (it seems more common to me than 'epoch', but I may be biased).

[ndw]

Why does that last example give incorrect results? Because "Z" is misisng?

[ChristianGruen]

Why does that last example give incorrect results? Because "Z" is missing?

…right. xs:date('1970-01-01') + seconds(...) could be another failed attempt, caused by the complexity of date/time handling.