## Types of changes
- [ ] I have read the **CONTRIBUTING** document.
- [ ] My code follows the code style of this project.
- [ ] I have updated the documentation accordingly.
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
- [ ] This is **NOT** translation related.
This closes issue #XXX
This is implements feature #YYY
This finishes chore #ZZZ
Since DateUtils does not need to store any data, wouldn't it be better to just have it as two expect functions?
In this way we remove the need of instantiating the object within the repository.
Moreover, if I'm not mistaken one of the two is full kotlin and could thus be in the common source.
Since DateUtils does not need to store any data, wouldn't it be better to just have it as two expect functions?
In this way we remove the need of instantiating the object within the repository.
Moreover, if I'm not mistaken one of the two is full kotlin and could thus be in the common source.
Since DateUtils does not need to store any data, wouldn't it be better to just have it as two expect functions?
It is now.
In this way we remove the need of instantiating the object within the repository.
I cleaned a little bit.
> Since DateUtils does not need to store any data, wouldn't it be better to just have it as two expect functions?
It is now.
> In this way we remove the need of instantiating the object within the repository.
I cleaned a little bit.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Types of changes
This closes issue #XXX
This is implements feature #YYY
This finishes chore #ZZZ
@@ -14,3 +7,1 @@actual fun parseDate(dateString: String): Long {val FORMATTERV1 = "yyyy-MM-dd HH:mm:ss"actual class DateUtils {Since DateUtils does not need to store any data, wouldn't it be better to just have it as two expect functions?
In this way we remove the need of instantiating the object within the repository.
Moreover, if I'm not mistaken one of the two is full kotlin and could thus be in the common source.
It is now.
I cleaned a little bit.