search

open-spaced-repetition / py-fsrs

Python Package for FSRS
https://pypi.org/project/fsrs/
MIT License
145 stars 23 forks source link

Proposition: Change Card's initial due state from UTC to Local time #23

Closed joshdavham closed 10 months ago

joshdavham commented 10 months ago

Currently, when a new Card object is created, it's due immediately with

self.due = datetime.utcnow()

This is using UTC rather than the user's local time.

I believe that, as most people will be using FSRS locally rather than hosted on a server somewhere potentially outside of their timezone, that it would be better to use the user's local time rather than UTC.

L-M-Sherlock commented 10 months ago

it would be better to use the user's local time rather than UTC

Could you explain it? I'm not professional in developing clients.

joshdavham commented 10 months ago

Honestly I'm not a professional at developing clients either so I'm not really sure what's ideal, it's just that it seemed odd to me that py-fsrs was using UTC rather than local.

For example, when I first started playing with py-fsrs, I hit a snag when I wrote code that looked like the following

fsrs

... and I got a bit confused.

Perhaps, it might just be better to let users know in the README that card objects are created using UTC rather than local time?

lex-neufeld commented 10 months ago

I suggest this issue be closed.

The cards being scheduled and reviewed in UTC is simple and functional and doesn't affect the user in any way. The Algorithm doesn't attempt to schedule things for times of day like "in the morning" (it just takes the current time and adds an interval to it), so the local time zone is not relevant.

Adding local time would only make sense as part of a major update to data collection and functionality. Such as developing an algorithm to detect what time of day a user learns/recalls best and reviewing cards accordingly even as they hop across time zones and go through DLST (Day Light Savings Time). Without adding functionality that is affected by local time, a switch from simple UTC adds complexity but no value. And really, if the algorithm detects that you learn best around 4am UTC and the App encourages you to review your hardest cards around that time and lets you blast through easy stuff at other times, it doesn't really matter if you are some kind of night-owl in London or on your Lunch Break in Shenzhen. Depending on implementation in the App, DLST or changing time zone still wouldn't necessitate accounting for Local Time as part of the scheduling or logging.

joshdavham commented 10 months ago

You make some good points, yeah I agree it should be closed.

I would like to see mention of the fact that the cards use UTC rather than local time in the README however as I suspect that I won't be the only developer who gets tripped up by this.

Last question before I close: If I submit a PR with a slightly updated README and it's get's merged, wil that also get updated on the PyPI page?

L-M-Sherlock commented 10 months ago

If I submit a PR with a slightly updated README and it's get's merged, wil that also get updated on the PyPI page?

Yep. If I pack a release, the GitHub action will automatically update the PyPI page.