5 ms·

A subscription will renew at 2025-08-16 04:04Z, and the billing system must send an email to the user reminding them of this. What date do you show in the email

A subscription will renew at 2025-08-16 04:04Z, and the billing system must send an email to the user reminding them of this. What date do you show in the email? A meeting happens every Tuesday at 9am, starting February 18, 2025. What time does the calendar show once DST kicks in?

DaiPlusPlus 1y ago
Systems can always translate UTC to a user’s own time-zone for display purposes, including accommodating DST; but internally all values are stored as UTC and all calculations are performed on UTC values.
- Hackbraten 1y ago
  That doesn’t answer the question of „What time does the calendar show once DST kicks in?“.
  - DaiPlusPlus 1y ago
    That’s up to the user’s preferences: their phone/computer’s timezone.
    - pbh101 1y ago
      The meeting is at a different time in UTC when DST kicks in.
      - DaiPlusPlus 1y ago
        Yes, but that’s handled by the user’s software when they access or edit the appointment. All calendaring software I know uses UTC internally like that, where the tz adjustments (including daylight savings rules - and historical too! are the responsibility of the topmost, user-facing parts of the system. I don’t know why I’m getting downvoted for saying this - am I missing something?
        rmah 1y ago
        If you set a recurring meeting, every Friday at 10:00AM, New York time, the time in UTC varies (either 14:00 UTC or 15:00 UTC) depending on the date. Further, what is displayed depends on the viewer's location (because daylight savings times change differently based on location/date). IOW, the time of the meeting occurs on TWO UTC times, not one. You can't just store UTC and be done with it. You need the originating timezone too. In other cases you may need the date the item was created as well. More sophisticated calendar software will take into account holidays or use offsets from month start/end. i.e. "we'll have a meeting at 9:00pm Tokyo time, every last business day of each month".
        DaiPlusPlus 1y ago
        > If you set a recurring meeting, every Friday at 10:00AM, New York time, the time in UTC varies (either 14:00 UTC or 15:00 UTC) depending on the date. > You can't just store UTC and be done with it Right; though there are different approaches to handling this in software; one approach is to create concrete (as opposed to virtual) records for each occurrence of the recurring pattern[1] so that any other software concerned with viewing/handling those events can be given precomputed UTC values and not have to worry about local user settings or parsing recurrence patterns. ...whereas another approach, which you mentioned, is to treat those occurrences as virtual-events derived from the (local-to-the-user) recurrence pattern, which requires the software to retain full timezone info (not just UTC offset) for the pattern, which increases software complexity (not to put it down; I'm simply saying that each approach has its benefits and drawbacks). [1] For practical reasons, systems like these only generate concrete records for, say, 1-2 years out into the future (and retain the ability to mass-update their individual occurrence times when the user's pattern specification changes). So what you say is true - and demonstrates that my desire for UTC-only systems is unworkable... but only for this particular scenario. Fun-fact: I have a legit copy the four specs in ISO 8601 ($500, ouch!) , and buried in ISO 8601-2:2019 section 7.3.1 there's an admission of inadequacy: > Representations of local time of day as defined below make no provisions to prevent ambiguities in expressions that result from discontinuities in the local time scale (e.g. daylight-saving time) ...whereas if everyone used UTC everywhere all-the-time for everything (i.e. ban daylight savings time!) then this problem wouldn't exist and my original point that started this whole thread remains true :3

DaiPlusPlus 1y ago

Systems can always translate UTC to a user’s own time-zone for display purposes, including accommodating DST; but internally all values are stored as UTC and all calculations are performed on UTC values.

Hackbraten 1y ago
That doesn’t answer the question of „What time does the calendar show once DST kicks in?“.
- DaiPlusPlus 1y ago
  That’s up to the user’s preferences: their phone/computer’s timezone.
  - pbh101 1y ago
    The meeting is at a different time in UTC when DST kicks in.
    - DaiPlusPlus 1y ago
      Yes, but that’s handled by the user’s software when they access or edit the appointment. All calendaring software I know uses UTC internally like that, where the tz adjustments (including daylight savings rules - and historical too! are the responsibility of the topmost, user-facing parts of the system. I don’t know why I’m getting downvoted for saying this - am I missing something?
      - rmah 1y ago
        If you set a recurring meeting, every Friday at 10:00AM, New York time, the time in UTC varies (either 14:00 UTC or 15:00 UTC) depending on the date. Further, what is displayed depends on the viewer's location (because daylight savings times change differently based on location/date). IOW, the time of the meeting occurs on TWO UTC times, not one. You can't just store UTC and be done with it. You need the originating timezone too. In other cases you may need the date the item was created as well. More sophisticated calendar software will take into account holidays or use offsets from month start/end. i.e. "we'll have a meeting at 9:00pm Tokyo time, every last business day of each month".
        DaiPlusPlus 1y ago
        > If you set a recurring meeting, every Friday at 10:00AM, New York time, the time in UTC varies (either 14:00 UTC or 15:00 UTC) depending on the date. > You can't just store UTC and be done with it Right; though there are different approaches to handling this in software; one approach is to create concrete (as opposed to virtual) records for each occurrence of the recurring pattern[1] so that any other software concerned with viewing/handling those events can be given precomputed UTC values and not have to worry about local user settings or parsing recurrence patterns. ...whereas another approach, which you mentioned, is to treat those occurrences as virtual-events derived from the (local-to-the-user) recurrence pattern, which requires the software to retain full timezone info (not just UTC offset) for the pattern, which increases software complexity (not to put it down; I'm simply saying that each approach has its benefits and drawbacks). [1] For practical reasons, systems like these only generate concrete records for, say, 1-2 years out into the future (and retain the ability to mass-update their individual occurrence times when the user's pattern specification changes). So what you say is true - and demonstrates that my desire for UTC-only systems is unworkable... but only for this particular scenario. Fun-fact: I have a legit copy the four specs in ISO 8601 ($500, ouch!) , and buried in ISO 8601-2:2019 section 7.3.1 there's an admission of inadequacy: > Representations of local time of day as defined below make no provisions to prevent ambiguities in expressions that result from discontinuities in the local time scale (e.g. daylight-saving time) ...whereas if everyone used UTC everywhere all-the-time for everything (i.e. ban daylight savings time!) then this problem wouldn't exist and my original point that started this whole thread remains true :3