Fork me on GitHub
#datalevin
<
2022-02-13
>
Huahai00:02:40

I don’t think date before 1970 is possible, because we are storing dates in unix epoch time https://en.wikipedia.org/wiki/Unix_time

Huahai00:02:57

which starts on 1970

Huahai00:02:06

basically, :instant is stored as a long of millisecond since 1970/01/01

Huahai00:02:33

you could use other data types, e.g. string, and do your own conversion.

Norman Kabir13:02:41

Thanks, @huahaiy! Is this because LMDB is written in C? I'm trying to wrap my head around the JavaScript origin of DataScript, C of LMDB, and Clojure of Datalevin 😉

Eugen13:02:06

@huahaiy (and @nkabir): if lmdb is storing only bytes then it's up to us (the app) to interpret thoese bytes how we want, no? :If we choose to interpret 8 bytes as an instant from 1970 - then yes, we can't refer to older dates. If we choose to store and interpret 8 bytes as a date only (no time) we get a very big range. One example is PostgreSQL's date and time: https://www.postgresql.org/docs/13/datatype-datetime.html .

timestamp [ (p) ] with time zone 	8 bytes 	both date and time, with time zone 	4713 BC 	294276 AD 	1 microsecond

date 	4 bytes 	date (no time of day) 	4713 BC 	5874897 AD 	1 day

interval [ fields ] [ (p) ] 	16 bytes 	time interval 	-178000000 years 	178000000 years 	1 microsecond

Eugen13:02:47

btw @huahaiy: does data levin offer any support for the new java time api https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html ? I imagine it uses java.util.Date for compatibility reasons. Looking at the API, one might be able to de/serialzie new Java time API's by implementing a custom https://docs.oracle.com/javase/8/docs/api/java/time/temporal/TemporalAccessor.html - to read date from raw bytes stored in a lmdb buffer. and using e.g localdate.from(TemporalAccessor) method https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html#from-java.time.temporal.TemporalAccessor- . Would this be something usefull ?

Norman Kabir14:02:23

> timestamp [ (p) ] with time zone 8 bytes both date and time, with time zone 4713 BC 294276 AD 1 microsecond @eugen.stan this range is more than sufficient for anything I would need. I am implementing the examples from http://www.learndatalogtoday.org/ They are storing birthdays in the #inst field. It would be nice to retain as much fidelity as possible with their examples. If someone can point me to the relevant logic in Datalevin, I can try to create a pull request (assuming @huahaiy supports the idea). Also, I can create a gist for the Datalevin Github with those implementations (and workarounds) to help people understand how to use this library. It is a great piece of software.

Eugen14:02:19

I would be happy to help - initially with testing and maybe some review. I also think lmdb and datalevin are great.

Norman Kabir15:02:01

I initially created an issue here. Dennis asked me to post here. It may be easier to track this with the issue but I'll follow whatever convention the community prefers. https://github.com/juji-io/datalevin/issues/94

Eugen21:02:25

I think having only the instant type from 1970 is very limitting.