Feature/issue 123 #129
Feature/issue 123 #129
Conversation
|
@satabin sorry for the delay on this. I've split it into two commits, one with the changes and another where I apply scalafmt to all the things. I noticed this when I ran scalafmt as part of the process that a bunch were out of format. If you'd like I can remove that commit. I also went ahead and added in the other java.time classes just for completeness. Thanks so much for the opportunity and this awesome project! I'm currently using it at work and it's been a huge help. |
|
ohh looks like a test I added broke, gonna look at that right now |
|
Hello @brbrown25, Thanks a ton for the contribution, I will go ahead and review it tonight. Regarding formatting, it might be that master is not properly formatted, if that's the case, I'll do it directly on master, and add a PR check to ensure master is always formatted in the future. You don't need to do it in this PR. I am super glad to read this project is useful for your work and hope it will continue fitting your use cases. |
brbrown25
force-pushed
the
feature/ISSUE-123
branch
2 times, most recently
from
47dc50b to
3c21ec7
Compare
|
@satabin it looks like scala js only shows UTC and GMT as zones, hence the failing test. to get around this I added a js and jvm version rather than having them in shared. it seems slightly related to cquiroz/scala-java-time#257 which I might try and look at later this week |
brbrown25
force-pushed
the
feature/ISSUE-123
branch
from
442e374 to
0fef6a4
Compare
|
Update, turns out if I add in the time-zone db dependency my original issue with the js test failing goes away, so I've updated with that. |
…for encoding and decoding java.time classes. gnieh#123.
brbrown25
force-pushed
the
feature/ISSUE-123
branch
from
0fef6a4 to
672261a
Compare
No description provided.