3 ms·

but school starts at 9am the nth of september not 2024-09-15 09:00:00

by afiori 2y ago

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)

but school starts at 9am the nth of september not 2024-09-15 09:00:00

by afiori 2y ago

but school starts at 9am the nth of september not 2024-09-15 09:00:00

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)