sandstorm

sandstorm copied to clipboard

It would be useful to be able to query a user's preferred timezone. Right now my znc port is spitting back all of the playback timestamps in UTC, which is less than ideal.

Relevant IRC discussion:

https://freenode.irclog.whitequark.org/sandstorm/2017-03-23

From the IRC discussion I see that you considered using client-side Javascript but were unhappy that it only gives you the current offset, where you want to know when DST happens, etc.

Unfortunately this is a rat hole. The world is full of wacky time zones with unexpectedly complicated rules. New time zones are created and eliminated by political decree on a regular basis. Rules are changed by political decree on a regular basis. Often there is little advance warning.

Given the complexity, time handling tends to be very app-specific. In the vast majority of cases, the right answer is "store everything in UTC and let the browser localize on display". For a few apps -- e.g. calendars -- it really matters, and the app is likely to need its own internal settings tailored for its needs. (E.g. timezone is a setting in Google Calendar, not in your general Google account.)

So, I think we probably shouldn't attempt to provide this. :(

If ZNC really needs a timezone specified in advance, you'll probably need to create a UI to configure this as part of your app. :/

Having slept on it I came to more or less the same reasoning/conclusion. I have looked at tge tzdata changelogs, and they're... Impressive. As it turns out, znc does have a setting for the timezone, which I will have to fuss with.

I'm going to go ahead and close this.

So, @zenhack, you opened this before... I feel like we should reopen it for revised modern-day discussion. But I have some specific thoughts:

It's really irritating to have to set your time zone independently for various Sandstorm grains. Especially if you have multiple calendars or the like. It'd be ideal for this to be a Sandstorm profile setting. (With the default being either to pass through the server's time zone, which is correct for self-hosters, and usually not that far off for cloud hosters, or based on the browser offset.) It seems to me that Linux systems provide the tzdata, and that there should be some way for us to use that which is on the system Sandstorm is installed on, rather than "providing it ourselves". Which rolls into the second issue I've been thinking about...

I recently had a bug on Ian's TTRSS package where my timezone, America/Chicago, got left out of the TTRSS package, and hence caused errors. There's a few reasons this is a dumb problem. For one, it's very easy for a package maintainer to miss a tzdata file: They won't notice it when testing. And second, with Sandstorm packages often being updated rarely, this means tzdata is going to be wrong/out-of-date for most packages. Luckily in America, this doesn't change frequently or significantly enough to be problematic. But especially once we have a calendar app, it could be really irritating if @zenhack had to push SandCal updates just to include updated tzdata files.

Is it practical or reasonable that Sandstorm should mount the system-provided tzdata for grains, such that grains need not include it, and it's updated along with the OS updates?

So, additional context, as my more recent interest came up in the context of SandCal, a calendar app, which per @kentonv's comment above really really needs to care about time zones, not just utc offset.

Right now I do have a setting in SandCal for the user to set their time zone, but having it in the grain is a little annoying, since it means you have to set your time zone for every grain.

Is it practical or reasonable that Sandstorm should mount the system-provided tzdata for grains, such that grains need not include it, and it's updated along with the OS updates?

This doesn't really solve the problem, since the issue is that I don't have a way to detect what the user's time zone is.

Revisiting this, I don't think it would actually be too hard for sandstorm to provide this -- ultimately all I think we need is to add a dropdown to settings where a user can pick their timezone; we can populate this from tzinfo, and just pass in the symbolic name as a string -- we don't really need to process it. Keeping up with the latest rules is just a matter of keeping one dependency up to date. The one complication is that it probably means anywhere Sandstorm needs to convert to the user's timezone, we'd possibly need to query tzinfo for a utc offset rather than just asking the browser. But none of this seems like that big of a maintenance burden as long as Sandstorm itself isn't doing anything special with time zones.

Another way to alleviate the annoyance for SandCal would be for there to be some way to define a setting for all grains of a given app, or at least a default value for a per-grain setting.

This doesn't really solve the problem, since the issue is that I don't have a way to detect what the user's time zone is.

I am interested in addressing two different issues here. 1. That Sandstorm let you set time zone data on your profile, which could be available to apps via a header like your display name is. 2. That Sandstorm should provide the time zone info for grains so that they don't have to bundle those files themselves, and so they are updated independently of app updates.

Because if you publish SandCal, and then a user's county's DST changes, SandCal would, under the current model, not recognize that until you update the app. Whereas if /usr/share/zoneinfo was provided to the grain by Sandstorm from the host OS, it would be current with whatever updates their Linux system, right? This would also prevent the discrepancy where Sandstorm lists a time zone setting in the profile that the grain didn't include/doesn't recognize.

(Does /usr/share/zoneinfo contain any sensitive/fingerprint-worthy info? Is there any reason an app should ever modify the contents of /usr/share/zoneinfo? Is there any reason an app should only include part of it, or have a reason to specifically not want that info present?)

the timezone database is not sensitive. We could pull the package in from upstream ourselves if we don't want to worry about fingerprinting based on possible distro modifications.

Adam makes a good point in IRC that shipping our own would also ensure apps run regardless of what server they're run on. Arguably, tzdata being updated in monthly Sandstorm releases is still far more accurate and current than relying on whatever is packed in a given SPK file.

I discovered today that there is actually a way to detect the user's time zone (not just utc offset) from the browser:

new Intl.DateTimeFormat().resolvedOptions().timeZone

...so that probably handles my use cases for SandCal.

Re: My questions on this issue about potentially serving all apps a standard tzdata: Mexico is apparently changing their DST rules with less than a week's notice, so any apps reliant on tzdata for that will now be annoyingly out of date in a relatively large country: https://twitter.com/simonw/status/1586753759496916992?s=46&t=f1EKPYxzIKLzkWiBQo8JQQ

We don't have a localization for them yet though, so I suspect we have a limited footprint there.