temporenc / temporenc-python

python library for the temporenc format

Temporenc for Python

This is a Python library implementing the temporenc format.

• Online documentation
• Project page (Github)
• Temporenc website

temporenc-python's Issues

use attrs instead of hand crafting a class for deserialised data

write docs for packb() and all its args

packing time zone aware datetime.time() instances fails

>>> temporenc.packb(datetime.datetime.now(datetime.timezone.utc).timetz())
Traceback (most recent call last):
  File "<ipython-input-11-4382b914e27d>", line 1, in <module>
    temporenc.packb(datetime.datetime.now(datetime.timezone.utc).timetz())
  File "/home/uws/Projects/temporenc/temporenc-python/temporenc/temporenc.py", line 544, in packb
    value = value - delta
TypeError: unsupported operand type(s) for -: 'datetime.time' and 'datetime.timedelta'

The standard library doesn't support this, it seems. From https://docs.python.org/3.4/library/datetime.html#datetime.timedelta:

"[...] although note that arithmetic on time objects is not supported."

Since we're working with fixed offsets anyway, it should be possible to do the arithmetic ourselves before encoding.

add proper __version__ symbols

• Add as symbol in top level package
• Use in setup.py
• Use in doc/conf.py

implement time zone handling for native types

write usage/tutorial

Add support for Arrow in API

It would be nice to have support for Arrow types (http://crsmithdev.com/arrow/) out of the box.

maybe add shortcuts for unpacking directly to native types

Perhaps it makes sense to have shortcuts to unpack directly to a datetime.datetime (and siblings), instead of going through an intermediate Moment instance. This would be mostly for performance reasons, since unpackb(b).datetime() is already pretty short and idiomatic.

Raise ValueError if the padding bits for DTS and DTSZ types are non-zero

…since this goes against the spec.

maybe rename 'local' arg to 'as_utc'?

use underscores for missing parts in string representation

...instead of a question mark which is not only harder to read, but may also give the wrong impression of "unknown", while it actually means "not set".

rename "moment" to "value"

Ensure leap seconds can be converted to native types

...but only when strict is `False.

make Value.datetime() faster

… by not calling both combine(self.date(), self.time())

Implement Z=126 special case

Temporenc now has a special Z=126 value: temporenc/temporenc#2

This should be handled sensibly in temporenc-python.

Demonstrate conversion from/to common date/time formats

Hi,

I accidentally stumbled across a StackOverflow article where you recommend temporenc and it immediately caught my attention as I generally like to use "normalized" date formats (instead of obscure epoch-based formats) and I am currently contemplating if I want to go with temporenc (I'm quite positive, though).

I immediately found that I, and probably everybody else, need algorithms for converting to and from the following common formats: Windows 64-bit time stamps, Unix 32-bit time stamps, ISO this-and-that long string representations, etc.

It would be a great help for everybody who contemplate using your new format, I think, if you could research and provide sample code for converting forth and back between the most commonly used formats.

You may argue that this is not your responsibility, which I'd sort of agree with, but I think it could help the adoption rate of your new format quite a bit, if you (or somebody else) supplied the above.

I found a couple of links of relevance to this request:

1. Microsoft blog.
2. Python code.
3. date decode using Python.

Cheers,
Archfrog

Add LICENSE

Check whether decoded fields are within allowed range

Implementation hint: instead of having a bunch of FOO_MIN and FOO_MAX constants, this could be a range() (xrange() on Python 2) instance, which supports the in operator.

Python optimization?

I made a basic benchmark for the python implementation. I just used the first thing I found when searching for "python benchmark"; maybe there are better options?

Anyway, the upshot is that on my machine python generally takes about 100-200 microseconds to serialize or deserialize 100 objects (so a couple of microseconds on average per object, though that's not really how it works). This is probably fine in practice, so I don't want to give the impression that I'm saying this is an urgent problem or anything.

Now for the totally unfair comparison. My rust implementation has been built for speed: it only ever allocates on the stack, is in a language with a fast compiler, etc, so it's not doing the same job as the Python code is. But, it is fast. Encoding and decoding objects (into pre-existing buffers) for the same 100 objects takes between 200 and 1400 nanoseconds, if my benchmarks are to be believed.

So, I thought it might be interesting to explore if it's possible to have an alternate back-end for the Python code that uses the Rust code for byte wrangling. I definitely want to keep a painless, easy-to-understand Python implementation for users who can't compile Rust code and for all the interop value of having another independent implementation. On the other hand, if this is something that's interesting to you, and there are things I can do in the Rust codebase (or not do) to make such a thing easy and/or feasible and that don't require regular Rust users to bend over backwards or anything like that, then it seems like it could be fun. Hypothetically the interop between Rust and Python's C API should not be a huge obstacle. I've done Rust/C interop in other projects and it's fine.

There's still more I need to build in the Rust library for this to be feasible, like polymorphic deserialization (where you don't already know what type you're about to deserialize), but I wanted to float the idea now just in case.

make `temporenc.Value` hashable

…so that it can be used as a key in a dict, for instance.

Maybe rename `Value` class

Maybe Moment is a better name?

implement comparison methods for temporenc.Value