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

Futureproofing: Improve datetime handling #214

Open
sbrl opened this issue Oct 30, 2020 · 0 comments
Open

Futureproofing: Improve datetime handling #214

sbrl opened this issue Oct 30, 2020 · 0 comments
Labels
Area: Code It's got something to do with code enhancement Let's make it better!
Milestone

Comments

@sbrl
Copy link
Owner

sbrl commented Oct 30, 2020

Currently, Pepperminty Wiki handles dates as UNIX timestamps. This is fine, but it isn't particularly future-proof. I think it's about time we do some proper date and time handling, using PHP's DateTime class. We should do this soon - the longer we leave it, the bigger job and more unpleasant it's going to be later..... just like a few other issues here (e.g. #187).

This will also have the side effect that the page index will become easier to edit the dates & times by hand, which is a nice addition.

The standard we're going to adopt is ISO 8601, with all datetimes being stored in UTC (regardless of the server's time zone, the time zone of the user who made an edit, or any other timezone). We can set the timezone on a DateTime like this:

$datetime_obj->setTimezone(new DateTimeZone("UTC"));

This will change the timezone to UTC - but it will also adjust the time too so that it still represents the same absolute point in time, just in UTC instead of whatever it was originally.

Things to remember when making this change:

  • We need to fix all references to lastmodified properties in the page index
  • Don't forget all references to timestamps everywhere
  • History revision timestamp handling will need to be adjusted too.
  • We'll need to maintain backwards compatibility - this will probably done via a migration function

Regarding that last point in particular, my current thought is to have a setting that defaults to false that's checked on start that if it isn't set to true will trigger the migration function. Perhaps it could be called something like datetime_migration_complete perhaps?

Relevant docs:

@sbrl sbrl added enhancement Let's make it better! Area: Code It's got something to do with code labels Oct 30, 2020
@sbrl sbrl added this to the v0.23 milestone Oct 30, 2020
@sbrl sbrl changed the title Futureproofing: Improve date handling Futureproofing: Improve datetime handling Oct 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Code It's got something to do with code enhancement Let's make it better!
Projects
None yet
Development

No branches or pull requests

1 participant