A local time is not tied to a timezone. When I set my wake up alarm at 8:30 every day, it should stay at 8:30 regardless of the current timezone. If I travel to the USA, my phone shouldn't start waking me up at 22:30.

▲

shmerl 3 days ago | parent | next [-]

Local time is irrelevant when you present that time to someone else external. How would they know what your local timezone is? This presentation tells them nothing about it.

So it's good for local use, but inadequate for any use that's not tied to your local environment. Alarms and etc. are already using it, so it's not about that use case.

▲

bsaul 3 days ago | parent | prev [-]

The datetime mentionned in parent post had both a date and a time component, which has the meaning of a "point in time". Not just a "time". Point in time needs location information to guess the timezone, otherwise you simply can't make anything out of it.

Your definition would have been just storing "hh:mm:ss".

▲

tsimionescu 3 days ago | parent | next [-]

That's a good point, I hadn't thought of that part. Local times can make sense, but datetimes really should always have a location timezone associated.

	▲	yencabulator a day ago \| parent [-]
		I have an application that receives a feed of availabilities, like the fact that you could reserve an item or service on 2025-10-20 at 13:00, it is currently available. The feed is global and the location of the business is a human-input address with potential errors, sometimes but not always has GPS coordinates (that may also be incorrect), and often where the actual service will happen is not the same as the location of the retail business. Yeah. It's just whatever 1 in the afternoon means in the local time, at the time of the reservation. I don't know what the timezone is. But they definitely have dates!

▲

ivan_gammel 3 days ago | parent | prev [-]

You are right that LocalDateTime requires location, but it is not part of the data type and data format. It’s just date and time without timezone and location is stored separately.

▲

fauigerzigerk 3 days ago | parent [-]

>You are right that LocalDateTime requires location

No. If I set a reminder for a particular date and time in the future, I want it to go off at that local date and time wherever I may be.

The location cannot be part of the data type because "local" is sometimes relative to movable objects.

▲

ivan_gammel 2 days ago | parent | next [-]

I don’t understand your objection. Local date and time is always bound to a local timezone, it‘s just implicit. Even in case of movable objects, the exact moment of time is defined by the watch aboard that object. You are on a ship and you wake up at 7am to get ready for breakfast? The exact moment of time when it happens is in the local time zone. The bar around the corner opens at 4pm? It’s in the local timezone, no matter how it changes. And „local“ means the timezone is defined by location, a ship, a city etc, so to calculate the exact moment of time you do location timezone lookup. Your phone does that automatically, picking up the timezone from cell tower and adjusting your local clock, so that alarm set at 7 (which is LocalTime) would work correctly.

▲

1718627440 2 days ago | parent [-]

> Local date and time is always bound to a local timezone, it‘s just implicit.

It does not that's the key of this argument. Here local means "on this device", whatever dumb time this has.

▲

ivan_gammel 2 days ago | parent [-]

Do you understand what „implicit“ means?

	▲	1718627440 2 days ago \| parent [-]
		Yes, but it's still not bound to a timezone, unless you define "all the timezones this device goes through" as a timezone.

▲

bsaul 3 days ago | parent | prev [-]

good point, never thought of that.