A printed calendar and a calendar app can describe the same event in different ways. The important part is that they cover the same dates. Before exporting an ICS file, check the selected range, the final included day of a longer event and any repeating dates that fall inside that range.
Understand what an all-day event represents
An all-day event belongs to a calendar date rather than a precise instant. A birthday on March 8 is about March 8; it is not an appointment at midnight that needs to be converted to another time zone. MonthSprig uses date-only values for its calendar events so the chosen date stays the chosen date.
In an ICS file, a date value has the form YYYYMMDD. For March 8, 2027, that is 20270308. A date-only start property can be written as DTSTART;VALUE=DATE:20270308. This is useful when reading or checking a file, but you do not need to type that syntax into the editor. Enter the ordinary calendar date in the event form.
Read the last day in the editor literally
In MonthSprig, the end date you choose is included. A trip from March 29 through March 31 occupies March 29, March 30 and March 31. Check those three dates in the preview before exporting. If the trip also includes April 1, change the visible end date to April 1; do not adjust it because of how a file format works.
ICS uses a different convention: DTEND is the first date after the event. The March 29–31 example therefore has DTSTART;VALUE=DATE:20270329 and DTEND;VALUE=DATE:20270401. That April 1 value does not add a fourth day. It marks where the event stops. Keeping this distinction clear helps explain a file without changing the dates a person entered.
Keep a time label separate from a timed appointment
You can place a label such as “14:30” or “After school” beside an event. It makes a printed calendar easier to use, but it remains text. It does not define a time zone, a duration or a reminder. Exporting the event must not silently turn that label into an appointment with a time-zone interpretation you never selected.
If you need a precisely timed meeting in another calendar service, create or check its time there. MonthSprig’s ICS output is for the date-based events described by the project. Review the imported entry before relying on it as a timed appointment, particularly when sharing a calendar between people in different time zones.
Review repeated dates before the download
A weekly event returns on its chosen weekday. A monthly event set to day 31 skips months without that day, and an annual February 29 event skips non-leap years. Check the occurrences you intend to include in the export range. A skipped February occurrence is different from an import failure or an event moved to February 28.
For a month-end review beginning January 31, 2027, the dates through May are January 31, March 31 and May 31. February and April do not contain day 31. If you want a meeting on the last day of every month, enter the dates that fit that plan; do not assume that a rule for day 31 has that meaning.
Choose the file that matches your next task
Use ICS when you want to move event dates into a compatible calendar app. Use event CSV when you want a table that you can inspect in a spreadsheet. Use PDF or PNG when you want the designed calendar page. These files serve different purposes: an event file does not preserve every visual choice from a printed layout.
Keep a JSON project backup if you want to reopen the editable MonthSprig project with its layout and settings. An ICS import into another service is not a connection to the original project. Editing the MonthSprig calendar later does not automatically update a file you already downloaded or an entry someone imported elsewhere.
Check one import before moving a large calendar
Try a small example first: one single-day event, one three-day span and one repeated event whose dates you can verify easily. Read the imported calendar entries and compare their dates with the source project. Check the last day of the span and any special text in titles or notes, especially if those contain commas or line breaks.
When the result is what you expect, use the same process for the larger range. Review how the receiving app handles another import of the same file so you do not create unwanted duplicates. Its import behavior is controlled by that app. Keep the original JSON backup and a clear file name so you know which version you moved.