DateTime time value table doesn't provide enough information

As a Roblox developer, it is currently too hard to derive more information about the current date using DateTime. The time value table returned from ToUniversal/LocalTime provides very primitive information about the date but I wish to see other information about a date such as

  • Day of the week (1-7, starting Sunday)
  • Day of the year (1-366)
  • Daylight Savings (boolean, default to false with ToUniversalTime)
  • Time Zone (abbreviated/full string, default to UTC with ToUniversalTime)

Of the list above, I am able to get the first two but I am required to use format strings and as a result the information I get back is strings but I want numbers. If I use ToUniversalTime or ToLocalTime, none of these items will not be provided in the returned time value table.

If Roblox is able to address this issue, it would improve my development experience because I could fully use DateTime to my advantage in order to create periodic data identifiers and in-experience timers that accurately tell the end user when they can expect an event to occur in their time zone. Accuracy for timing is super important when it comes to LiveOps and content cadence so users can plan their play time around dates especially for limited time events.


There are certain time-based liveops features I really want to build around DateTime, but without these keys it’s more difficult than it needs to be to derive certain values. I’ve stopped using with the introduction of DateTime but it simply doesn’t give me enough information.

Additionally, regardless of whether I use DateTime or, it feels incredibly improper to use formatting API just to bypass this issue. I’ve always like DateTime right off the bat because of the values being provided as a Luau table but I’m not sure why it’s missing keys and format flexibility that’s otherwise offered by As a datatype it’s great but informationally it’s regressive.

I really hope this can be addressed.

1 Like

I am still heavily invested in liveops features in my experiences and I’m always continually downtrodden to find out that DateTime is only superior to in terms of the API but informationally it is still inferior to doing an abominable coercion of a date format string to a number.

I want to use DateTime to get more information about the date natively without using some library that ultimately has the same unintuitive dependency - or worse, dependency on a third party server. DateTime lacking keys relative to the year and locale sucks for trying to create features based on real time which is an otherwise very common use case.

Please, could I get some signal? Any attention from product or engineering?

This is a great idea, as a programmer I sometimes find that I need the players information to directly get special / more information about rewards (or whatever I use it for). Someone needs to do this because it’s needed.

Hoping to get some support and likeminded developers on board with this so engineers can see that a solid use case for having this exists. Live ops features are great for experiences and it’s one of the types of features Roblox pushes us to include for player engagement and retention - and I agree that they are great for those two things as well.

Right now, it’s too difficult or tedious to get this data without using other APIs incorrectly whether or not we use a custom library (particularly that we have to coerce strings into numbers). This isn’t ideal. DateTime’s date table should provide us with extensive information so we can better develop our live ops features and use properly typed data.

why don’t you just use tick() or os.time()?

I came on this exact issue recently. It it really hard to properly do LiveOps on this platform. What we have now is great for static post-launch things but, LiveOps treats this approach as a service that is constantly updated with new content, features, etc to keep the player-base engaged.

So things like personalization and dynamic content (without hacky / dirty workarounds) is hard to execute. Having accurate timekeeping to synchronize events, offers, etc in a fair manner for all players warrants a solid use-case for this imo.


1 Like

I’m looking for a date table, not a UNIX timestamp. Please read the thread before replying.