How long should a session absolute timeout be?

There is no strict answer to the time length. The limits of idle timeouts depend on regulations and possibly jurisdictional laws.

Session-based access to cardholder data in PCI DSS 3.1 is required to be "reasonable". PCI DSS 3.1 in item 8.1.8 provides specific guidance on this

8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session.

SOURCE: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

Similar suggestions exist for other compliance programs. Making it configurable and flexible according to data sensitivity context is likely your best bet.

Absolute timeouts aren't mandated under any framework I know of, but they do seem interesting. The user experience impact is potentially significant, but the benefit of limiting the duration of a session hijacking is also significant. It seems like a better solution - if you control the application code - would be session rotation (ie: a Renewal Timeout in OWASP parlance) whereby the application generates a fresh session ID periodically.

I recommend pursuing a Renewal Timeout if the application permits it and using a renewal timeout no greater than 1 hour. This substantially reduces the hijacking risk and should be practical with any application that has a straight-forward (small and manually copyable) or serializable session state.

If Absolute Timeout is your only option I would make the timeout 24 hours. It's a sensible limit and limits surprise. A multi-day absolute timeout would likely confuse users as they'd see the re-prompt as arbitrary or potentially indicative of application failure.