5 ms·

> You want three pieces of information, a date, a location and a local time. Note that I do not think you actually want a time zone, what if you are not in Lond

> You want three pieces of information, a date, a location and a local time. Note that I do not think you actually want a time zone, what if you are not in London and that place gets moved into another timezone? Theoretical arguments are nice, but in the real world, meetings are regularly scheduled were one or all people aren't physically at the location, say the company's headquarters, but the local time zone and its DST shifts are obviously still respected.

danbruc 3y ago
Those are two different things, either you want local time at some location or in some time zone, just pick what you need or want. And going one step back, who really has to schedule things to a specific time so far into the future that uncertainty about time zone changes become a valid concern? There are certainly things like a space probe arriving at Pluto in a couple of years, but in such cases you will not care about the local time in London. Or a long running construction project, building some tunnel for two decades, but who would schedule the opening ceremony to a specific date and time two decades into the future?
- codeflo 3y ago
  Many regular events are scheduled "indefinitely" into the future. Do you really think that when the US changed its DST rules a couple of years back, any of the regularly scheduled weekly meetings were happening according to the old rules?
  - danbruc 3y ago
    Appointment series were the example that I gave earlier where you will have to use some more complex data structure than a simple date time value and corresponding logic to get it right. You can obviously not find the correct instants for a weekly meeting by repeatedly adding 168 hours to the instant of the first appointment. But this thread started from specifying a date and time of day in some place far into the future and I do not think an indefinite appointment series qualifies for this. Your scheduling application would most likely store something like every Tuesday and 13:00 and figure out the actual instants as needed, for example to show a reminder. And as it received updates about changed daylight saving time rules, it would recalculated the instants.

danbruc 3y ago

Those are two different things, either you want local time at some location or in some time zone, just pick what you need or want. And going one step back, who really has to schedule things to a specific time so far into the future that uncertainty about time zone changes become a valid concern? There are certainly things like a space probe arriving at Pluto in a couple of years, but in such cases you will not care about the local time in London. Or a long running construction project, building some tunnel for two decades, but who would schedule the opening ceremony to a specific date and time two decades into the future?

codeflo 3y ago
Many regular events are scheduled "indefinitely" into the future. Do you really think that when the US changed its DST rules a couple of years back, any of the regularly scheduled weekly meetings were happening according to the old rules?
- danbruc 3y ago
  Appointment series were the example that I gave earlier where you will have to use some more complex data structure than a simple date time value and corresponding logic to get it right. You can obviously not find the correct instants for a weekly meeting by repeatedly adding 168 hours to the instant of the first appointment. But this thread started from specifying a date and time of day in some place far into the future and I do not think an indefinite appointment series qualifies for this. Your scheduling application would most likely store something like every Tuesday and 13:00 and figure out the actual instants as needed, for example to show a reminder. And as it received updates about changed daylight saving time rules, it would recalculated the instants.