As a Roblox developer, using the DateTime data type isn’t elegant, because it does not provide oeprations for math (add, subtract) and ordering (less than, greater than) directly on the type as implemented. Constant access of UnixTimestamp or UnixTimestampMillis and recreating the type are required to do that currently.
I figure this is an easy win for the usability of this API.
If Roblox is able to address this issue, it would improve my development experience because I get to write less code.
Just convert it to a number (unix time) and do all the operations you need. This makes the most sense since math operations are meant for numbers. Only when you’re done should you convert it back to DateTime for final formatting (that’s the whole point of DateTime, to format the time). Doing math operations on the DateTime object itself doesn’t sound like a good idea since it opens up ambiguity on what exactly is being changed/compared (local time or unix time or the ISO date, etc.)
You can write functions to automate those things. This is probably the most underwhelming reason for a feature request.
No, it doesn’t. There is no ambiguity–DateTime internally represents a timestamp in UTC. It has methods to convert universal time or local time units into it, a method to convert an ISO date (which can represent timezones) into it, and it has methods to format itself as a universal time or local time. There is zero ambiguity in the time value itself, so comparing two DateTimes has obvious behavior.
This math portion of this feature request was not intended for DateTime + DateTime (which is fairly useless), it was intended for DateTime + number. Had you mentioned an operation between DateTime and number, you could argue there is ambiguity in the unit of number, seconds or milliseconds.
Considering every duration property or parameter in-engine is represented as a seconds float, and there is no engine Duration type (which would be more appropriate here) it is fair to assume seconds would be used.
There is a reason why many languages, including Luau, allow behavior to be associated with a type. You use these constructs often when you add two Vector3s. This is the exact same concept.
You could be comparing unix time with local time to check what time zone a player is in and if they’re ahead or behind. You could also be comparing the ISO date (the actual string values themselves) if you needed to order them by ASCII. It’s a niche behavior, but it’s a totally valid reason why comparison could be ambiguous, which is why you should stick with using unix time as a number datatype with number operations (gives more clarity and control) and not fiddle with the DataType object itself.
I am unable to find a widespread use case for this, which is why I believed this feature request is too niche and unnecessary; feel free to prove me wrong on this.
To construct a DateTime object, you input it a number. You have an opportunity to operate on this number before it is converted into DateTime for formatting. The only way to construct a DateTime without giving it a number is with the .now() method, which is equivalent to os.time(), unless you are trying to access the client’s local time, which is also rarely used in favor of unix time. Thus, usually when you are working with a DateTime object, you already know the unix time that it is carrying since it was most likely used in its own construction. So there is no need to have to do math operations on the DateTime object itself, for it can already be done with its precursor, that being the unix time you just assigned it with.
That’s a fair point, but there are also valid reasons why people have reservations over adding trivial features that have very common alternatives. It bloats up the class data structure which can affect performance. Complexity in general, regardless of how insignificant it is, makes things harder to learn and to work with. Luau the language is especially against adding features deemed too niche; you can see this effect in their RFC on features common elsewhere such as constant variables and function decorators.
I am not exactly against your feature request, but rather I am casting doubts and being overly critical.
You keep referring to comparing unix time with local time or comparing ISO strings, but this does not reflect how DateTime works. DateTime does not store multiple competing representations, it stores a single canonical UTC timestamp. All other representations (local time components, ISO strings, etc) are just views derived from that UTC timestamp.
Roblox provided this DataType, as it did others, to reduce boilerplate and improve clarity. Adding operator overloading to this type makes the API nicer to use. They exist to create predictable, idiomatic patterns.
I’m sorry, but this is simply ridiculous. Adding math ops to a type that is solely based around a number does not affect performance or bloat anything.