Razeeman
Add timezone when exporting CSV
Exported CSV file is missing timezone information, so it's hard to make sense of the data unless you know the exact timezone it was exported with.
This PR changes timestamp format to ISO8601/RFC3339, so it should be parseable by virtually any tool. (Unfortunately XXX requires API level 24 but I assume that's fine.)
Hello! Thank you very much for the suggestion. Can you please explain a little bit your use case? What problems are caused by not having a timezone there? I'd assumed that most users open exported file in the same timezone which is was exported in.
Can you please explain a little bit your use case?
My use case is exporting all records from STT to archive and analyze them later.
What problems are caused by not having a timezone there? I'd assumed that most users open exported file in the same timezone which is was exported in.
The problem is that this requires out-of-band knowledge of what timezone the records were exported in. While your assumption is correct for most users most of the time, it's not correct for all users all the time:
- Users might be traveling and changing timezones.
- Some countries observe daylight saving time, so in a month a lot of users' timezones will change.
- I might transfer and process my records on another machine with different timezone.
Overall, timezone-less timestamps are just ambiguous, not suitable for long-term storage, and complicate processing.
Thank you for the explanation. Makes sense. Unfortunately it seems that neither macos Numbers app or Google sheets don't recognize this format as a datetime format and show it as a simple text. This may break some people usecases. As an alternative time zone can be added as another column with the text like "GMT+7:00". Will it resolve the issue?
Just wanted to jump in and add my support and +1 to this issue - our system which consumes CSVs from this app has run into several problems recently with DST parsing due to the naive timestamps in the CSVs. If we could have some timezone data in the CSV files, it would greatly improve things!
If storing as standard ISO8601 UTC "Z" timestamps is not possible, perhaps we can store the timezone data as a separate column, as mentioned, or even have this be a configuration in the settings to write ISO8601 timestamps (if desired by the user) to CSV instead of naive local?
Appreciate both of your work on this app's development, it's truly a useful app for us! :)
@Firewolf34 Will return to this issue. Problem is that suggested in this PR java time format "2016-01-11T14:08:42+00:00" is not supported in old android phones, but it should be possible to add a column with time in ISO8601 UTC "Z" format (ex. "2025-11-05T05:51:40Z") or just UTC timestamps (ex. 1762334948).
What would be more preferable: adding timezone as a separate column to the csv file (like "GMT+7:00") or a separate column with time in ISO8601 UTC "Z" format (like "2025-11-05T05:51:40Z")?
Speaking personally, ISO 8601 UTC Z format is much preferred as a solid timekeeping standard for database use. In our use case, we are importing the CSVs into a Postgres database.
Added a few date format options to the csv export.
Local (default, current) - yyyy-MM-dd HH:mm:ss UTC - yyyy-MM-ddTHH:mm:ssZ Time zone (suggested in this PR, not available on old androids)- yyyy-MM-ddTHH:mm:ssXXX
Excellent!! Thanks so much for introducing this change! ❤️ It is much appreciated for our Time Tracking database project (soon to be open source as well). Appreciate your hard work on this awesome app!