Default date/time/timezone handling

[magnusjt]

Thanks for your work on this library! I haven't used it yet, but it looks interesting.

I'm wondering how dates, times, and timezones are handled by default in this project. In my experience, people tend to stick with the defaults (at least until the bugs start to show up), so it's important that they are sane. The existing mysql libs don't do a good job here. In my opinion, the defaults should be:

1. Dates and datetimes are returned as string (as opposed to Date objects) since they do not have timezone info
2. Timestamps should be parsed as UTC and returned as Date objects. This works because of the next point:
3. The mysql session timezone should be set to UTC by default ("SET time_zone='+00:00';")

What do you think?

[knoxcard]

@magnusjt This issue has been fixed in Sequelize
(Recommend using Sequelize as your ORM moving forward)

sequelize/sequelize#10705

[rusher]

@magnusjt
The current solution seems the most suitable in terms of ease of use but is based on having client and server configured according to the same timezone.

Handling client and server following different timezone is complex, the solution you describe would work well. The problem then would be letting user parsing timestamps and date string themselves, opening the door to mistakes.
I don't see any excellent solution, particulary because javascript doesn't have DATE / TIMESTAMP distinction, only Date object

[magnusjt]

@knoxcard I personally don't use sequelize, or any other orm's, so can't benefit from their fix

@rusher "The problem then would be letting user parsing timestamps and date string themselves, opening the door to mistakes." - The mistake would be to parse them using Date, imo..

The ease of use argument is fair, but will inevitably lead to bugs for many people. Maybe it's just a question of making this clear in the documentation, and easy to configure for different time zone on client and server?

[rusher]

Documentation never hurt.
I'll do that shortly, then post here reference for review/ideas.

[knoxcard]

Guess this issue can be closed now, after the most recent release?

[rusher]

better to keep it open as a reminder !

[knoxcard]

should we carry this over to JIRA and merge it with the other (similar) issue?

(Think this has been resolved already?)

[rusher]

closing, not an issue, but task, created as https://jira.mariadb.org/browse/CONJS-82