Arrow: Is there an easy way to get timestamp with microsecond from an arrow object, result like time.time()?

[liaoliaopro]

I would like to do convertion between timestamp and arrow/datetime:

1. timestamp with microsecond ==> arrow or datetime
2. arrow or datetime ==> timestamp with microsecond

1 has an easy way, but 2 I am frustrated to find one. time.mktime(datetime.timetuple()) does not work because timetuple() discards the microsecond portion. Does arrow already have a method to do this convertion or I miss something?

thanks.

[crsmithdev]

Arrow currently uses integer timestamps, and there's no way to get a floating-point timestamp out of the timestamp property. If I can find a nice way to make that available somehow I'd consider adding it.

[liaoliaopro]

Is it appropriate to add 'microsecond' property for arrow object? so if
user need a float timestamp, can simply write:

t = arrow.now()
float_timestamp = t.timestamp + t.microsecond/1e6

On Thu, Oct 10, 2013 at 11:06 AM, Chris Smith [email protected]:

Arrow currently uses integer timestamps, and there's no way to get a
floating-point timestamp out of the timestamp property. If I can find a
nice way to make that available somehow I'd consider adding it.

—
Reply to this email directly or view it on GitHubhttps://github.com/crsmithdev/arrow/issues/49#issuecomment-26026065
.

[crsmithdev]

You can already do exactly that:

>>> t = arrow.now()
>>> t.timestamp + t.microsecond/1e6
1381381932.358509

[liaoliaopro]

Great, thanks. not find the 'microsecond' property in doc before, it is the
getattr magic. could this be the way to implement the float timestamp?
IMHO, It makes sense to have a symmetric method/property to arrow.get() to
do conversion between arrow and timestamp. I searched in google and
stackoverflow, guess this requirement is very common.

arrow.get(FLOAT_TIMESTAMP).float_timestamp == FLOAT_TIMESTAMP

maybe float_timestamp is a bad name :)

On Thu, Oct 10, 2013 at 1:13 PM, Chris Smith [email protected]:

You can already do exactly that:

t = arrow.now()>>> t.timestamp + t.microsecond/1e61381381932.358509

—
Reply to this email directly or view it on GitHubhttps://github.com/crsmithdev/arrow/issues/49#issuecomment-26029557
.

[sametmax]

What about t.timestamp being a named tuple timestamp(seconds, microseconds) ? This will prevent people from searching, It makes the api very clear and self discoverable and it end the debate one and for all :

>>> t.timestamp.seconds
1381381932
>>> t.timestamp
timestamp(seconds=1381381932, microseconds=358509)

Plus it allows unpacking.

[crsmithdev]

I'll likely add something like the float_timestamp property. What we definitely do not want to be doing is changing the return value of timestamp as that would break many, many things.

[sametmax]

This is a 0.4 release, breaking things should not be a concern,
improving the API is. But float_timestamp seems a good solution to me
anyway. I don't even use it, it espacially useful for .net plateforms.

Le mar. 15 oct. 2013 22:04:22 CEST, Chris Smith a écrit :

I'll likely add something like the |float_timestamp| property. What we
definitely do not want to be doing is changing the return value of
|timestamp| as that would break many, many things.

—
Reply to this email directly or view it on GitHub
https://github.com/crsmithdev/arrow/issues/49#issuecomment-26367374.

[crsmithdev]

It's definitely a concern as many people (myself included) are using this in production at the moment, and even though I am below a 1.0 release, I'm trying to follow semantic versioning principles and NOT do breaking changes except on the most major (e.g. 0.3 -> 0.4).

[crsmithdev]

0.4.2 now has a float_timestamp property.

[sametmax]

I must raise a concern about using a float for this float_timestamp. I was suggersting a tuple because a float as precision issues. If you return a tuple second, microsecond, you won't have this problem. Returning a float has been deprecated in several languages (including Java, if I recall correctly) and has been debating to be put aside by the Python community.

[crsmithdev]

I'm fine using a float for two reasons: a tuple is a much clumsier return value to work with (a timestamp can be represented as an integer or floating-point number, and any timestamp property should return exactly one of those), and a Python float (assuming CPython, not sure about PyPy) is going to be internally represented as a double. That gives it more than enough bits to properly represent the microsecond portion of a timestamp.

[sametmax]

At least let's cast it to a Decimal from a string to avoid rounding
problems : http://www.python.org/dev/peps/pep-0410/

Le mar. 29 oct. 2013 22:50:50 CET, Chris Smith a écrit :

I'm fine using a float for two reasons: a tuple is a much clumsier
return value to work with (a timestamp can be represented as an
integer or floating-point number, and any timestamp property should
return exactly one of those), and a Python float (assuming CPython,
not sure about PyPy) is going to be internally represented as a
double. That gives it more than enough bits to properly represent the
microsecond portion of a timestamp.

—
Reply to this email directly or view it on GitHub
https://github.com/crsmithdev/arrow/issues/49#issuecomment-27346940.

[crsmithdev]

That PEP was rejected. Again, it's going to stay as it is.