Cannot have a non-24 hour in-experience day

As a Roblox developer, it is currently too hard to create or simulate an in-experience day that adheres to non-24 hour time scales (e.g. day lasting for either 12 or 48 hours). If I would like to adjust my timescales, I am required to scale my time adjustments according to my desired length (e.g. 12-hour days must be scaled 200%, 48-hour days must be scaled 50%). Even if I can do this, it’s too difficult to represent this visually such as on a clock display.

If Roblox is able to address this issue, it would improve my development experience because I could successfully and comfortably create fantasy worlds where a day is not 24 hours long. Being able to configure how many hours are in a day would allow me to pursue my imaginative worlds with shorter or larger timescales than Earth’s. As a developer who creates and really enjoys science fiction media, it’s not uncommon that I find myself not wanting to conform to 24-hour days.

16 Likes

First, let’s see how we normally would display time in a 24 hour clock using math:

local function toHMS(s)
	return string.format("%02i:%02i:%02i", s/60^2, s/60%60, s%60)
end
  • s/60^2, how many times an hour (3600 seconds) has been past s seconds.
  • s/60, how many times a minute (60 seconds) has been past s seconds (1 hour = 3600 seconds). s/60%60, how many minutes remain after every hour (60 minutes).
  • s%60, how many seconds remain after every minute (60 seconds).

Now, about creating in-experience days:

Create a new unit, in here I’ll be calling “inexday”, kinda like the Sol.

You can use math to figure this out. I can think of a few ways you could do this:

  1. A day can contain multiple inexdays (most useful) or an inexday lasts multiple days (more confusing). For simplicity we keep the same day, month, year, etc as earth.
  2. A day is actually an inexday and the way we count time on Earth is scaled accordingly (1 sec is actually 1 inexsec, and so on), since the unix epoch.
  3. Like 1, but you create a totally new calendar based on the earth second. (Good luck)

Case 1

Let’s define our unit, for example

local INEXDAYS_PER_DAY=2 --You can call this "scale" instead, since its not just for days

Let’s display our local time in earth using DateTime:

local function getTime()
	local timeTable = DateTime.now():ToLocalTime()
	return timeTable
end

local function format(timeTable)
	local dateTime = DateTime.fromLocalTime(timeTable.Year, timeTable.Month, timeTable.Day, timeTable.Hour, timeTable.Minute, timeTable.Second, timeTable.Millisecond)
	return dateTime:FormatLocalTime("LLL", "en-us")
end

print(format(getTime()))

Now we can calculate inextime and keep earth days and inexdays:

local function getTime()
	local now = DateTime.now()
	local timeTable = now:ToLocalTime()
	local inexTimeTable = DateTime.fromUnixTimestamp((now.UnixTimestamp % (24*60*60))*INEXDAYS_PER_DAY):ToLocalTime()
	timeTable.Inexday = inexTimeTable.Day
	timeTable.Inexhour = inexTimeTable.Hour
	timeTable.Inexminute = inexTimeTable.Minute
	timeTable.Inexsecond = inexTimeTable.Second
	timeTable.Inexmillisecond = inexTimeTable.Millisecond
	return timeTable
end

local function formatInex(timeTable)
	local dateTime = DateTime.fromLocalTime(
		timeTable.Year, 
		timeTable.Month, 
		timeTable.Day, 
		timeTable.Inexhour, 
		timeTable.Inexminute, 
		timeTable.Inexsecond, 
		timeTable.Inexmillisecond
	)
	return dateTime:FormatLocalTime("LL", "en-us")
		.. (" Inexday: %02d "):format(timeTable.Inexday)
		.. dateTime:FormatLocalTime("LT", "en-us")
end

print(formatInex(getTime()))

Case 2

We just multiply the unix timestamp and assume the inex time started since the unix epoch

local function format(datetime)
	return DateTime.fromUnixTimestamp(datetime.UnixTimestamp*INEXDAYS_PER_DAY):FormatLocalTime("LLL", "en-us")
end

print(format(DateTime.now()))
3 Likes

Due to my abuse of DateTime, which doesn’t fit as nicely for the use case of in-experience days, you cannot have more in-experience days than the maximum of the current month (~30 days). You can still fix it using remainders and division while scaling the time, however you might still want to DateTime it if you want to use our calendar, with each month having its specific days, leap days and seconds.

I’m not sure I’m really following your proposed alternative here. The idea is that I don’t want to go through this inane complexity just to have a day that lasts non-24 hours. To me, that mostly just says “allow a value different from 24 to define when ClockTime resets to 0”. Real life time is irrelevant to me. Even if it’s a sound solution, I can’t use it if I don’t fundamentally understand it - and that’s just me, not including any novice developers who may also may want to have non-24 hour days but don’t have the experience to implement any overengineered alternative.

1 Like

Call this everytime you want to set the ClockTime property:

local Lighting = game:GetService("Lighting")

local function setClockTime(hour, hoursInADay)
	Lighting.ClockTime = ((hour/hoursInADay)*24) % 24
end

For example a day with 100 hours, the 50th hour being midday, and 100th being noon.

setClockTime(50, 100) --> midday
setClockTime(100, 100) --> noon
2 Likes

I think just allowing different number of hours per day is not flexible enough. What if you want multiple celestial bodies that all emit different light, different lengths for morning/night/afternoon, etc.

This should probably be tagged on onto an existing feature request to support more custom skies and transitioning between skies. Maybe the time can then be managed by setting a cframe rotation that is applied to the celestial bodies of the sky, without needing a notion of “hours”.

An extension of above for non-programmers would be that you could set your own tweens for how time progresses in the game from 0 to 1, and defining which skies are present at which rotations and how much they contribute at each tween position.

8 Likes

That’s a good point! I actually did think about the lengths of days but not really if developers may want to add more skies for certain points of day. I’ll try and tack this on to another feature request, I felt it may have been reaching too far if I tried to cover too much.

I’ll try and find a suitable feature request that generally covers the bulk of what I’m looking for since I don’t doubt there’s a few on more lighting control.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.