> Relative dates like “Today” and “Tomorrow” can be easier to understand.

This is one of those ideas that sounds like a good idea on paper, but can be an actual nightmare to implement. There are so many edge cases that can occur that you need to think about, especially once you get into cases like "this time next month". What if daylight savings time trips? What about time zones? What if it is January 31st and you want something a month from now? What if it is 12:05 at night and someone asks for 4PM tomorrow?

You should think long and hard before offering relative time options in program.

Montreal public transit times used to be on some kind of like, 28-hour clock. Bus times after midnight would be labelled 27:30 or something. Suuuper confusing. It sounds so bizarre in fact, that I'm doubting my memory a bit, but I'm certain it was like that (say around 2006 or so).

This is actually how GTFS (a standard format for public transit data) works: https://gtfs.org/documentation/schedule/reference/#stop_time... . Especially sleeper trains can get weird with 30+ hours. But I don't think it's wise to show that to the user

And it is the right thing to do as otherwise the question to which day a train belongs will be confusing. Just take it %24hours before intersecting trains.

It is also how I personally record time spans. It makes it much easier as you do not need to deal with the case where the start is larger than the end time and you can only have a single date field.

I've seen this in Japan as well. A store that's open from, let's say, 8am to 1am will actually advertise itself as being open from 8am to 25pm. I guess the perception is that it's confusing to have a range where the smaller number comes before the bigger number.

Japanese are used to it because TV shows etc. that have the same issue.

If it airs at 2025-11-24 01:00, people will have an easier time to remember it's at a very late after the 23th's midnight, than a crazy early time on the 24th. Most TV or movie guide will show it as 25:00 on the 23th.

I think it is more common for them to write 8:00 to 25:00 - omitting AM and PM.

AM and PM is used in a few languages (mostly English) but many don't have it in their vocabulary at all, which probably includes Japanese.

In the case of Japanese, there is 午前・午後 for 12-hour time. e.g. 午後９時に着く (arrive at 9 P.M.). If it's obvious from context, then only the hour is said. e.g. in「明日３時にね」, the flow of the conversation disambiguates the hour (it's also unlikely the speaker means 3 A.M.)

There are also other ways to convey 12-hour time. e.g. 朝６時に起きる (wake up at 6 A.M. / wake up at 6 in the morning).

And even if they have, representations of noon and midnight differ.

Maybe at that point they should say "Closed 1am to 8am" instead.

UK buses and trains do this.

I think the reason is for Day return tickets ie those where you can go out and come back on the same day. It allows the return to be after midnight which makes sense for example going to a theatre show or pub that shuts at 11pm

I work with a factory that uses 32 hour timestamps, as some employees work a night shift.

i hate that computers define 'today' and 'tomorrow' on days centered on midnight.

several times this has lead to problems when i'm doing a late-night work binge that cross into 12am and i see relative date terms that confuse me.

if you're out with some friends and it's 12:15 AM and you say "i really need to go, i have a big day tomorrow" it's understood that that means the big day is on this calendar date but after i wake up and NOT the following day.

> Except when you're booking a flight and you're not sure whether "today" is based on your local time, the server's local time, or GMT.

But the same issue exists with explicit dates like "November 12".

Not really, because the standard in air travel is that departure and arrival dates and times are always local to the departure or arrival airport, regardless of where you are when you book the flight (or what time it is locally when you book).

and yet google calendar by default translates them into the current (GPS-based) timezone ....