Oops, I think this may be redundant with #1641

Oops, I think this may be redundant with #1641

This ticket is written way better though!

Blocking this ticket on the autostart UI work. As @vapurrmaid mentions, it will likely be easier to refactor after those pieces are in place, in 1 PR like we did for ttl together

Something else to consider is a time-based instead of duration-based approach to auto-off, following the logic in #2141.

We need to document that we only support IANA Time Locations, and not time zones for the TZ input.

If you look at this list, https://en.wikipedia.org/wiki/List_of_tz_database_time_zones, the value must be in the TZ database name. The schedule library uses time.LoadLocation.

This is a bit unfortunate as timezones like CST and CDT are not supported (although daylight savings is a headache on it's own). From a brief look a the time api, we cannot convert CDT -> America/Chicago either. (Which makes sense because CDT is a large zone, America.Chicago is a singular location).

I think the 2 timezones people will use is UTC and Local. Anything else seems pretty niche.

Currently we don't support Local.

schedules scoped to time.Local are not supported

I wrote a brief PR (https://github.com/coder/coder/pull/2207/files) on how we can use time.Local to infer local timezone using w/e golang does by default. Then we just convert the Local -> UTC time and submit that to the API.

We need to document that we only support IANA Time Locations, and not time zones for the TZ input.

100%

This is a bit unfortunate as timezones like CST and CDT are not supported (although daylight savings is a headache on it's own).

This is probably for the best. Having daylight-savings-time-specific timezones in a schedule is probably going to lead to confusion.

I wrote a brief PR (https://github.com/coder/coder/pull/2207/files) on how we can use time.Local to infer local timezone using w/e golang does by default. Then we just convert the Local -> UTC time and submit that to the API.

If whoever uses this lives in a location where daylight savings time is active, storing their autostart time in UTC will cause bugs.

If whoever uses this lives in a location where daylight savings time is active, storing their autostart time in UTC will cause bugs.

I didn't think about this. I wonder if we have this issue in v1. If we handle TZ parsing manually, we could maybe support zone syntax?

This part of the code makes it look like we can set the location manually?

I wonder if this works? Then we can support more common zones?

tz, _ := time.Parse("MST", "CDT")
schedule.Location = tz.Location()

Or alternatively, just tell them to use IANA locations. Maybe add this code to catch the common mistake of using a zone name. It is confusing the output text uses a zone

The steven workspace will automatically start at 2022-06-10 10:39:00 -0500 CDT.

if strings.Contains(err.Error(), "provided bad location") {
  _, err := time.Parse("MST", autostartTimezone)
  if err == nil {
    // We should find a nice easy list to use.
    return xerrors.Errorf("It appears you have entered a timezone, try using a location from the IANA location list https://gist.github.com/aviflax/a4093965be1cd008f172")
  }
}

I just want to be completely clear here: not supporting time zones like CDT or EST is a feature. We never want to support those because they they don't adapt to human needs and expectations.