7 ms·

Why would anyone choose to use local time for anything other than display? That just seems way harder even if you don't have customers from other timezones.

mafuy 2y ago
Yup. The only exception I could think of are prearranged local times, e.g. the meeting will be on -future day- at -local time-. In that case, if, say, the time zone changes, the meeting would still be at the same local time and not move.
- jiehong 2y ago
  True, but also for the past, actually. Because DST might be a thing right now in that zone, but may no longer be next year, in which case the historical DST is needed to refer to times in the past. Same for dates a bit further back when countries changed calendars and some days are missing. So, we basically need a mapping of UTC -> local time as a function of time, and store this forever. (For durations, we might need to have a mapping from TAI to UTC as a function of time, because a leap second messes with duration length. Smeared leap seconds are even worse in that regard)
skissane 2y ago
> Why would anyone choose to use local time for anything other than display? You need to store it for certain applications, e.g. timetabling. if school starts at 9am, it starts at 9am local time, and if local time changes (DST, or more rarely a change in the time zone rules) then school start time runs with it. Or similarly, if a commuter train timetable has it stopping at a certain station at 7.05am, that’ll be local time in the local time zone.
- afiori 2y ago
  but school starts at 9am the nth of september not 2024-09-15 09:00:00
  - skissane 2y ago
    I know a bit about the computer system at our children’s school. I only have access to the parent portal, but that’s enough to give me some idea how it actually handles things. Plus I used to work for a university, and I got a good look at the internals of its system - and timetabling isn’t fundamentally different between primary/secondary and tertiary, just it gets more complicated as you move up. So, to answer what I think you are saying - normally you divide the day into chunks (“periods”). At our children’s school, it is primary, there are only two notional periods a day (morning and afternoon), when our son goes to secondary school next year (which appears to use the same software) there will be several periods a day, one per a subject. Anyway, in the system, a period is a class, not just in the academic sense, but also in the OO sense, and as such it has instances - “morning period” starts at 8.35 am local time any day the school is open. So that start time would be stored without a date, just a time plus time zone. But then, there is an instance of “morning period” every one of those days, which starts at a particular instant in time - today it starts at 2024-07-04T08:35+10:00. And yes, you could store that just in UTC, and convert to the school’s local time on display. I suppose there are three main data types you really need: (1) date without time (2) local time in specific timezone (3) UTC instant For (1), whether you need the timezone or not depends on the use case. For stuff like dates of births, you generally won’t know and don’t really need to know the timezone in which they were born. But, for other applications, it becomes important, since Wednesday afternoon in the Americas is Thursday morning in Oceania and eastern Asia, so whether it is Wednesday or Thursday depends on your timezone. People expect days to start and end at local midnight, not UTC midnight - which for me is 10 or 11 o’clock in the morning. For hire dates, many jurisdictions have employment laws that have different rules depending on how long you’ve worked there. So you need to know how many days since hire to know what legal regulations apply to the employee. And obviously that is meant to be calculated in local time, if you do it in UTC or HQ timezone it could be a day out, which might cause legal issues. (e.g. in some jurisdictions it is easier to fire an employee in the first six months, you wait until the last day to terminate them, except because you got the day off by one, that was yesterday, now you have terminated them illegally)
- josephg 2y ago
  I arrived 1 hour late to an online meeting once in which I was scheduled to give a talk. The root cause was this: I (in Australia) was subscribed to the event calendar. The event was actually a reoccurring event at the same time every month in UTC time. But day or so before the event happened, daylight savings changed in LA - which for some reason was the time zone the calendar was set to. As a result, the meeting in my local Australian time drifted by an hour. Unfortunately, only some people used the online calendar. So many people (including the organisers) showed up on time. Time zones are a curse on humanity.
  - delecti 2y ago
    Time zones are totally fine. They're unreasonably hard to do math with (ahead/behind +/- just refuses to stick in my brain), but they massively simplify life most of time they come up. The thing that's a curse on humanity is daylight saving time.
    - digging 2y ago
      > they massively simplify life most of time they come up. I have coworkers and friends in different timezones, and timezones do literally nothing but complicate coordination. Even if it's a small friction, they are 100% friction. As far as I can tell, the main benefit of timezones is that it allows people within the same timezone to converse as if timezones don't exist. Which would also be the case if timezones didn't exist.
      - delecti 2y ago
        Historically speaking, the alternative to time zones is not one unified time, it's thousands or millions of time bubbles for each town's solar noon.
        digging 2y ago
        Yes, but we're not speaking historically.
    - 2y ago
dspillett 2y ago
If your application's use is local enough that more than one timezone isn't a concern, and doesn't much (or at all) care for things that span overnight, so you don't have to worry about adding/dropping an hour to the length of things when some sort of DST event happens, just using local time across the board is simply easier. Of course as soon as one of those assumptions is not 100% true, using UTC internally and local time for display is usually by far the better option (though there can still be difficulties there – time is never as easy as you'd think it should be). The trouble comes when people use to working local only (timezone wise) slap together a PoC of something that might need timezone awareness, and don't fix the deficiency at any point as they progress through PoC->prototype->alpha->beta->v1. The longer you leave the change the harder it is to do, and it not being easy is why once something nominally reaches V1 (or often at first alpha release) such a fix is seldom ever made. Timezone awareness has improved massively in recent years though. I think some cloud providers have accidentally helped there by defaulting to UTC (for instance all AzureSQL DBs default to UTC for everything, as do VMs and other things in Azure). Though here in the UK minor issues due to bad assumptions are still common when we transition back or forth between GMT and BST.
- outworlder 2y ago
  Yeah, and even if those assumptions are perfectly fine today, they are unlikely stay that way. When they do, going back and fixing everything else is a massive pain. Even ensuring everything is in localtime can be a pain; someone decides to add a database you didn't have before and didn't pay enough attention to its configuration? Too many landmines. The way to avoid this pain is to just use UTC on day one, regardless of requirements. Hard and fast rule that everything needs to be UTC. Need to display it? Converting to local time is trivial. Same thing for text. Use Unicode unless otherwise specified.
  - dspillett 2y ago
    > just use UTC on day one, regardless of requirements That can cause extra concerns for always-in-one-timezone systems where you might care where midnight falls (“did this event happen today or yesterday?” is a question that needs extra steps to answer, for instance). Nothing complicated, but extra work you might want to skip at the quick PoC stage. But yes, beyond PoC work and all but the simplest other work, I'd agree with UTC all the way from the ground up.

mafuy 2y ago

Yup. The only exception I could think of are prearranged local times, e.g. the meeting will be on -future day- at -local time-. In that case, if, say, the time zone changes, the meeting would still be at the same local time and not move.

jiehong 2y ago
True, but also for the past, actually. Because DST might be a thing right now in that zone, but may no longer be next year, in which case the historical DST is needed to refer to times in the past. Same for dates a bit further back when countries changed calendars and some days are missing. So, we basically need a mapping of UTC -> local time as a function of time, and store this forever. (For durations, we might need to have a mapping from TAI to UTC as a function of time, because a leap second messes with duration length. Smeared leap seconds are even worse in that regard)

skissane 2y ago

> Why would anyone choose to use local time for anything other than display? You need to store it for certain applications, e.g. timetabling. if school starts at 9am, it starts at 9am local time, and if local time changes (DST, or more rarely a change in the time zone rules) then school start time runs with it. Or similarly, if a commuter train timetable has it stopping at a certain station at 7.05am, that’ll be local time in the local time zone.

afiori 2y ago
but school starts at 9am the nth of september not 2024-09-15 09:00:00
- skissane 2y ago
  I know a bit about the computer system at our children’s school. I only have access to the parent portal, but that’s enough to give me some idea how it actually handles things. Plus I used to work for a university, and I got a good look at the internals of its system - and timetabling isn’t fundamentally different between primary/secondary and tertiary, just it gets more complicated as you move up. So, to answer what I think you are saying - normally you divide the day into chunks (“periods”). At our children’s school, it is primary, there are only two notional periods a day (morning and afternoon), when our son goes to secondary school next year (which appears to use the same software) there will be several periods a day, one per a subject. Anyway, in the system, a period is a class, not just in the academic sense, but also in the OO sense, and as such it has instances - “morning period” starts at 8.35 am local time any day the school is open. So that start time would be stored without a date, just a time plus time zone. But then, there is an instance of “morning period” every one of those days, which starts at a particular instant in time - today it starts at 2024-07-04T08:35+10:00. And yes, you could store that just in UTC, and convert to the school’s local time on display. I suppose there are three main data types you really need: (1) date without time (2) local time in specific timezone (3) UTC instant For (1), whether you need the timezone or not depends on the use case. For stuff like dates of births, you generally won’t know and don’t really need to know the timezone in which they were born. But, for other applications, it becomes important, since Wednesday afternoon in the Americas is Thursday morning in Oceania and eastern Asia, so whether it is Wednesday or Thursday depends on your timezone. People expect days to start and end at local midnight, not UTC midnight - which for me is 10 or 11 o’clock in the morning. For hire dates, many jurisdictions have employment laws that have different rules depending on how long you’ve worked there. So you need to know how many days since hire to know what legal regulations apply to the employee. And obviously that is meant to be calculated in local time, if you do it in UTC or HQ timezone it could be a day out, which might cause legal issues. (e.g. in some jurisdictions it is easier to fire an employee in the first six months, you wait until the last day to terminate them, except because you got the day off by one, that was yesterday, now you have terminated them illegally)
josephg 2y ago
I arrived 1 hour late to an online meeting once in which I was scheduled to give a talk. The root cause was this: I (in Australia) was subscribed to the event calendar. The event was actually a reoccurring event at the same time every month in UTC time. But day or so before the event happened, daylight savings changed in LA - which for some reason was the time zone the calendar was set to. As a result, the meeting in my local Australian time drifted by an hour. Unfortunately, only some people used the online calendar. So many people (including the organisers) showed up on time. Time zones are a curse on humanity.
- delecti 2y ago
  Time zones are totally fine. They're unreasonably hard to do math with (ahead/behind +/- just refuses to stick in my brain), but they massively simplify life most of time they come up. The thing that's a curse on humanity is daylight saving time.
  - digging 2y ago
    > they massively simplify life most of time they come up. I have coworkers and friends in different timezones, and timezones do literally nothing but complicate coordination. Even if it's a small friction, they are 100% friction. As far as I can tell, the main benefit of timezones is that it allows people within the same timezone to converse as if timezones don't exist. Which would also be the case if timezones didn't exist.
    - delecti 2y ago
      Historically speaking, the alternative to time zones is not one unified time, it's thousands or millions of time bubbles for each town's solar noon.
      - digging 2y ago
        Yes, but we're not speaking historically.
  - 2y ago

dspillett 2y ago

If your application's use is local enough that more than one timezone isn't a concern, and doesn't much (or at all) care for things that span overnight, so you don't have to worry about adding/dropping an hour to the length of things when some sort of DST event happens, just using local time across the board is simply easier. Of course as soon as one of those assumptions is not 100% true, using UTC internally and local time for display is usually by far the better option (though there can still be difficulties there – time is never as easy as you'd think it should be). The trouble comes when people use to working local only (timezone wise) slap together a PoC of something that might need timezone awareness, and don't fix the deficiency at any point as they progress through PoC->prototype->alpha->beta->v1. The longer you leave the change the harder it is to do, and it not being easy is why once something nominally reaches V1 (or often at first alpha release) such a fix is seldom ever made. Timezone awareness has improved massively in recent years though. I think some cloud providers have accidentally helped there by defaulting to UTC (for instance all AzureSQL DBs default to UTC for everything, as do VMs and other things in Azure). Though here in the UK minor issues due to bad assumptions are still common when we transition back or forth between GMT and BST.

outworlder 2y ago
Yeah, and even if those assumptions are perfectly fine today, they are unlikely stay that way. When they do, going back and fixing everything else is a massive pain. Even ensuring everything is in localtime can be a pain; someone decides to add a database you didn't have before and didn't pay enough attention to its configuration? Too many landmines. The way to avoid this pain is to just use UTC on day one, regardless of requirements. Hard and fast rule that everything needs to be UTC. Need to display it? Converting to local time is trivial. Same thing for text. Use Unicode unless otherwise specified.
- dspillett 2y ago
  > just use UTC on day one, regardless of requirements That can cause extra concerns for always-in-one-timezone systems where you might care where midnight falls (“did this event happen today or yesterday?” is a question that needs extra steps to answer, for instance). Nothing complicated, but extra work you might want to skip at the quick PoC stage. But yes, beyond PoC work and all but the simplest other work, I'd agree with UTC all the way from the ground up.