Anybody interested in joining? Very very early sta...
# opensource
m
Anybody interested in joining? Very very early stage multiplatform date & time library. https://github.com/fluidsonic/fluid-time Idea is to have something in between the
java.time
API and Swift's date/time API, multiplatform starting with JVM & iOS. At first it'll make use the underlying platform APIs (using threeten backport for Java, native for iOS) while building a good common API. Over time more and more of the underlying API can be replaced with own common code. Be aware that everything involving time zones, date/time calculations and date/time parsing is a shitload of work 😄
🎉 4
j
Good luck with it! I've been working on one called
lokalize
and there's already a
klock
that most people use. +1 for going with good naming conventions on your types. I might suggest using
inline class
to make the whole thing more efficient. You have my explicit permission (though the license already covers it) to pull whatever you might want from
lokalize
for
fluid-time
. You're also welcome to contribute to mine too if you'd like.
m
Thanks @josephivie. What's your library about? Have a link for me? Also feel free to copy whatever you need. What would you inline? I try to use inline whenever I can but staying close to the Java time API makes that mostly impossible
j
https://github.com/lightningkite/lokalize Ah, I missed that you were focused on staying close to
java.time
. I'm very much not, so I just used an inline class for my time stamp, using milliseconds since 1970 - I just haven't needed that level of precision on time stamps yet, and I built mine strictly for being able to make my multiplatform UI library.
n
Joseph Ivie - Did you take into account the Year 2038 Problem ( aka Unix time doomsday - https://en.wikipedia.org/wiki/Year_2038_problem )?
Further information about the "The Unix Time Apocalypse" can be found here: http://unixepoch.com/
m
Well he uses
Long
so it should be fine 🤔