Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timezone issues #134

Closed
dannyvankooten opened this Issue Sep 21, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@dannyvankooten
Copy link
Collaborator

dannyvankooten commented Sep 21, 2018

While storing statistics on a daily basis in UTC dates has upsides, it has two pretty big downsides:

  • For people ahead of UTC, their "today" view will always be empty if they're checking their stats early on in the day.
  • For people behind UTC, their "today" view will be finished already while stats are already being collected for the next day if they're checking later on in their day.

An improvement would be to store statistics by the hour, that'll also give us a chart to show on the "today" view. It would increase storage size by a factor 24 however.

@dannyvankooten dannyvankooten added the bug label Sep 21, 2018

dannyvankooten added a commit that referenced this issue Sep 21, 2018

take timezone offset into account to fix today view. stick to utc for…
… those ahead of utc... see #134 (needs a better fix)
@ghost

This comment has been minimized.

Copy link

ghost commented Sep 23, 2018

Sounds like a dashboard UI and tracking issue. My expectation would be to capture time in two ways:

The latter of which would be used when viewing the dashboard to allow time traveling.

@dannyvankooten

This comment has been minimized.

Copy link
Collaborator Author

dannyvankooten commented Sep 23, 2018

dannyvankooten added a commit that referenced this issue Oct 30, 2018

fix timezone issue for dates coming from pikaday, which are not takin…
…g wintertime into account somehow. relates to #134
@t3hmrman

This comment has been minimized.

Copy link

t3hmrman commented Nov 13, 2018

What about forcing the inclusion of UTC in calculations, and creating the proper ways to set default offsets for the application and users overall?

I know it sounds pretty radical, but the fact that Fathom aggregates "daily" stats means that it needs the concept of a "day", and days just don't make sense without a given timezone (very literally, someone's day in one timezone is another person's night).

It would be a huge change, but I think it would be the right way to handle such a change. Writing software that deals with time is hard but IMO the cleanest way to handle it is to embrace the complexity and make it explicit since it's a core requirement of the functionality (daily rollups require knowing what a day is).

on the other hand, you could do some extra work and calculate "24 hour" rollups, and let the user pass in an optional offset to know which one to pick?

dannyvankooten added a commit that referenced this issue Nov 13, 2018

switch to hourly storage for stats.
- allows showing an hourly chart on the 'today' view
- fixes timezone issues when in 'today' view #134
- increases size of stats tables by factor 24, but that should be less of an issue after dbcadcd
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.