3 ms·

I’m having a hard time following how such naive time handling became part of a Google product. Pick an epoch for timekeeping. Timezones are a display issue.

by mulmen 2y ago

crote 2y ago
No, it isn't. That approach works fine for things like logging where are your timestamps are in the past, but the moment you have to deal with future timestamps it leads to some truly horrible issues when some political leader decides to change the definition of the timezone. Suddenly all your future epoch-based datetimes are representing the wrong wall clock time...
- londonlawyer 2y ago
  [dead]
- mulmen 2y ago
  Timekeeping is always epoch based. When the definition changes you update the display code. There’s no way to write code today that accounts for future changes in local time.
  - hansvm 2y ago
    That's the same kind of mentality that kept Google Calendar from being able to schedule a monthly meeting on the last day of the month. If you scheduled it on the 31st, the tool would happily accept that 5 months each year wouldn't have your monthly meeting. Suppose I have an 8am alarm to wake up in the morning. I want that to happen once per day in my current local timezone. If I change locations, the epoch I'm being alarmed at should change. If I travel quickly enough to experience multiple 8ams, I only want one of them (the first one). If laws change to give me multiple 8ams in a single locale, it's ambiguous which one I want. How your alarm app handles that varies, but you should do _something_ (flag the situation in the app, pick one (if one of them is about the same epoch as the previous alarm, maybe pick that one), ...). For calendars you have probably a different set of choices. If all participants are in the same time zone, you probably want the meeting to move as regulations change the definition of 8am. If they're in different time zones which all practice daylight savings and the meeting doesn't conflict with any of the 1-2am haunted hours then the meeting should probably move with daylight savings, reference the local time as it was defined when the meeting was created, and not move as some dictator redefines a time zone (becoming a cross between a display issue and actually considering local time). If you don't know anything as a calendar app about the participants, there will be edge cases where you make bad decisions, so you either accept that or flag the ambiguity when appropriate. And so on. If we can convince everyone to switch to some kind of atomic time without leap seconds I'd be tickled pink. That's not the world we live in though.
    - mulmen 2y ago
      That’s the difference between the 31st and the last day of the month. It’s a UX issue, not a timekeeping issue.
  - toast0 2y ago
    Storing epochs for future times that are specified in local time usually isn't enough considering that local time zones change. If you only deal in times and time zones where time zone changes are announced far enough in advance that zone changes can be processed before any events they effect are in the system, it doesn't matter. But if people schedule things years out in countries with reasonable notice, or weeks out in countries where there's a lack of notice, there's a good chance of doing things wrong. To accomidate these future dates, you should store the localtime and you should also store the offset and/or an epoch determined at time of storage. When rules change, you should evaluate future events and for events where the calculated epoch changes, storing and using the new epoch is a sensible default --- you should ideally show the user a summary of changes, so they can adjust if they have things that were entered in local time for convenience but are actually scheduled in a different zone.
- Dylan16807 2y ago
  But the context of the article was logging and purely a display issue.
saagarjha 2y ago
Googlers are not all timekeeping experts, nor are they all capable of summoning that knowledge at all times when writing code.
- mulmen 2y ago
  It just seems like something Google would have solved in a general sense. It’s a hard problem, asking everyone to get it right is unrealistic, clearly.

I’m having a hard time following how such naive time handling became part of a Google product. Pick an epoch for timekeeping. Timezones are a display issue.

by mulmen 2y ago

I’m having a hard time following how such naive time handling became part of a Google product. Pick an epoch for timekeeping. Timezones are a display issue.

crote 2y ago

No, it isn't. That approach works fine for things like logging where are your timestamps are in the past, but the moment you have to deal with future timestamps it leads to some truly horrible issues when some political leader decides to change the definition of the timezone. Suddenly all your future epoch-based datetimes are representing the wrong wall clock time...

londonlawyer 2y ago
[dead]
mulmen 2y ago
Timekeeping is always epoch based. When the definition changes you update the display code. There’s no way to write code today that accounts for future changes in local time.
- hansvm 2y ago
  That's the same kind of mentality that kept Google Calendar from being able to schedule a monthly meeting on the last day of the month. If you scheduled it on the 31st, the tool would happily accept that 5 months each year wouldn't have your monthly meeting. Suppose I have an 8am alarm to wake up in the morning. I want that to happen once per day in my current local timezone. If I change locations, the epoch I'm being alarmed at should change. If I travel quickly enough to experience multiple 8ams, I only want one of them (the first one). If laws change to give me multiple 8ams in a single locale, it's ambiguous which one I want. How your alarm app handles that varies, but you should do _something_ (flag the situation in the app, pick one (if one of them is about the same epoch as the previous alarm, maybe pick that one), ...). For calendars you have probably a different set of choices. If all participants are in the same time zone, you probably want the meeting to move as regulations change the definition of 8am. If they're in different time zones which all practice daylight savings and the meeting doesn't conflict with any of the 1-2am haunted hours then the meeting should probably move with daylight savings, reference the local time as it was defined when the meeting was created, and not move as some dictator redefines a time zone (becoming a cross between a display issue and actually considering local time). If you don't know anything as a calendar app about the participants, there will be edge cases where you make bad decisions, so you either accept that or flag the ambiguity when appropriate. And so on. If we can convince everyone to switch to some kind of atomic time without leap seconds I'd be tickled pink. That's not the world we live in though.
  - mulmen 2y ago
    That’s the difference between the 31st and the last day of the month. It’s a UX issue, not a timekeeping issue.
- toast0 2y ago
  Storing epochs for future times that are specified in local time usually isn't enough considering that local time zones change. If you only deal in times and time zones where time zone changes are announced far enough in advance that zone changes can be processed before any events they effect are in the system, it doesn't matter. But if people schedule things years out in countries with reasonable notice, or weeks out in countries where there's a lack of notice, there's a good chance of doing things wrong. To accomidate these future dates, you should store the localtime and you should also store the offset and/or an epoch determined at time of storage. When rules change, you should evaluate future events and for events where the calculated epoch changes, storing and using the new epoch is a sensible default --- you should ideally show the user a summary of changes, so they can adjust if they have things that were entered in local time for convenience but are actually scheduled in a different zone.
Dylan16807 2y ago
But the context of the article was logging and purely a display issue.

saagarjha 2y ago

Googlers are not all timekeeping experts, nor are they all capable of summoning that knowledge at all times when writing code.

mulmen 2y ago
It just seems like something Google would have solved in a general sense. It’s a hard problem, asking everyone to get it right is unrealistic, clearly.