Addresses #1064 going forward

[micahmills]

by making all timestamps based on the start of the day utc not the local time

[corsacca]

Hey @micahmills
(https://disciple.tools/dev-docs/rest-api/post-types-fields-format/)
The API currently expects dates to be in 'yyyy-mm-dd' format. It then uses strtotime to convert the date into the unix time stamp which would result in a timestamp for the start of the day UTC.
Passing in the timestamp directly works, but requires the client to figure out the the right value like you've done here.
Thoughts on using yyyy-mm-dd instead?

[micahmills]

We could use the yyyy-mm-dd format but we lose the internationalization and formatting that we have with the formatDate functions (

disciple-tools-theme/dt-assets/js/shared-functions.js

Line 379 in d915605

formatDate(date, with_time = false) {

).

[corsacca]

Yes, for displaying the date we should continue using the formatDate() function. Makes the user's life much nicer.
When sending the updated value to the server we need to use the unix timestamp format or the yyyy-mm-dd format.
The api does the converting already when using receiving a date in the yyyy-mm-dd format, which is why i lean towards using it.

[micahmills]

Just so I am clear we would save the date in the YYYY-MM-DD format in the database then in the formatDate function we would convert it to a time stamp for the international formatting?

[corsacca]

Just so I am clear we would save the date in the YYYY-MM-DD format in the database then in the formatDate function we would convert it to a time stamp for the international formatting?

No, the API transforms it to a unix timestamp before it is saved in the DB.

[micahmills]

I believe that is what this PR does. The issue is that previously the time code were getting was midnight of the day selected in the users timezone not UTC. This should make sure that the saved time codes are for the start of day UTC.

For previously saved dates we will need to put together a plan for either updating all the old timecode or just know that they might be a day off for teams that are working across multiple timezones and have saved dates previous to this update.

[corsacca]

moment(date).unix() isn't correct because the time zone is off.
moment.utc(date).unix() is correct.
moment.utc(date).format('YYYY-MM-DD') would also be correct (and what the documentation says to send to the API). The server would convert to utc and save the timestamp to the DB.

I'm fine with moment.utc(date).unix() and added it to the groups page too.

[micahmills]

Should we do something with previously saved dates that might have the time stamp that is not utc? We could come up with a script to run through all the old dates and fix them but there will be some edge cases to plan for. Or we could just leave it as it is and know that previously saved dates might be off by a day for teams working in multiple time zones.

[corsacca]

For fixing historical data:
The theme and the app have updated dates at the same time, so it will be generally hard to know which ones are correct and which ones are not.
I think we can leave it and new dates going forward will be correct.

[micahmills]

Sounds good to me