Luxon: DateTime.toSeconds returns seconds.milliseconds

[ThorstenBux]

Hi,

I'm wondering why DateTime.toSeconds() does return a floating-point number xxxxx.yyy where yyy represents the milliseconds. If I wanted to have milliseconds I would have called .toMilliSeconds()

Expected:
DateTime.fromISO("2019-08-31T00:27:39.689Z").toSeconds() // --> 1567211259

Actual:
DateTime.fromISO("2019-08-31T00:27:39.689Z").toSeconds() // --> 1567211259.689

[icambron]

The reason people typically want toSeconds is that they want to pass the result a UNIX system that expects datetimes expressed as epoch seconds, and I believe those systems generally allow for decimals in the input. Thus, leaving in the milliseconds makes the conversion to that representation lossless.

You can alway call Math.floor() or Math.round() on it.

[ThorstenBux]

@icambron, thanks for clarification.

[krukru]

Hey @icambron, just found this issue after spending some considerable time debugging why my app doesn't work, because I would never expect toSeconds() to return seconds.miliseconds.
I think toSeconds should return exactly what the name suggests, and allow for a different method to return both seconds and milis.
Even better would be to explicitly return the result as an object, with properties seconds and miliseconds. Just return seconds, because it is very explicit about the expected return value/type

[vvo]

This was also a surprise to me

[carlholloway]

Likewise. I think at the very least the docs should be explicit that a decimal number is returned

[toddbluhm]

I just ran into this issue as well. I definitely think it should return just the seconds stripping the millis.

While I totally agree that toSeconds is primarily used for Unix systems (that's what I use it for too), the method is called toSeconds not toUnix. I would be completely happy with this behavior in a toUnix method, but toSeconds is pretty explicit about what it should return.

I would not change this to return an object as that is even less intuitive than the current behavior. toSeconds screams number, not object.

One other possibility is to have an option to enable milliseconds. Something like includeMillis in the options object.

Lastly, whether any changes are made, the current behavior should definitely be added/clarified in the docs 😄

[joepie91]

I think it's quite reasonable to return a fractional number here, and I don't think it has anything to do with UNIX timestamps. It's fundamentally just a unit conversion like any other, and those can be fractional; if you were to convert "1300 meters" to kilometers, you would also expect to get "1.3 km" and not "1 km".

This is different from extracting the amount of seconds, eg. 49 from 12:20:49, where it would be reasonable to expect only whole numbers; but that's not what this method does, it does a conversion.

From a practical perspective, it also makes sense; while you can round a fractional number, you cannot un-round a whole number. So returning just the whole seconds would make it impossible to get the fractional seconds from that.

That having been said: yes, this should be explicitly documented.

[arkabase]

I think you should update the example in the manual :

https://moment.github.io/luxon/docs/manual/formatting.html
dt.toSeconds(); //=> 1492702320 should be dt.toSeconds(); //=> 1492702320.000