datetime (convert_datetime_type) seems to add in extra milliseconds

[clarsen]

READ AND FOLLOW THESE INSTRUCTIONS CAREFULLY

ISSUES THAT DO NOT CONTAIN NECESSARY INFORMATION MAY BE CLOSED, IMMEDIATELY

The issue tracker is NOT the place for general support. For questions and
technical assistance, come ask the Bokeh mailing list or join the chat on Gitter. For feature requests, please provide a detailed description or proposal of the new capability or behavior.

For defects or deficiencies, please provide ALL OF THE FOLLOWING:

ALL software version info (bokeh, python, notebook, OS, browser, any other relevant packages)

version_json = '''
{
"date": "2017-06-13T09:22:29-0500",
"dirty": false,
"error": null,
"full-revisionid": "6070bf96d9367150f423a4fa792a7d242421236b",
"version": "0.12.6"
}

Description of expected behavior and the observed behavior

the function (snippet shown)
def convert_datetime_type(obj):
# Datetime (datetime is a subclass of date)
elif isinstance(obj, dt.datetime):
return (obj - DT_EPOCH).total_seconds() * 1000. + obj.microsecond / 1000.

that converts a datetime to json for use in plotting seems to not compute the timestamp properly.

Complete, minimal, self-contained example code that reproduces the issue

when I do this by hand with a datetime that has non-zero microseconds,

For the unix timestamp
1501131481.011143 . which has a converted d

>>> import datetime
>>> dt = datetime.datetime.fromtimestamp(1501131481.011143)
>>> dt
datetime.datetime(2017, 7, 26, 21, 58, 1, 11143)
>>> DT_EPOCH=datetime.datetime.utcfromtimestamp(0)
>>> dt-DT_EPOCH
datetime.timedelta(17373, 79081, 11143)
>>> (dt-DT_EPOCH).total_seconds()
1501106281.011143
>>> (dt-DT_EPOCH).total_seconds()*1000.
1501106281011.143
>>> dt.microsecond/1000.
11.143
>>> (dt-DT_EPOCH).total_seconds()*1000.+dt.microsecond/1000.
1501106281022.2861
>>> ((dt-DT_EPOCH).total_seconds()*1000.+dt.microsecond/1000.) - (1501131481.011143 * 1000.)
-25199988.856933594

If anything, the microseconds should be zero since we're just comparing milliseconds_since_epoch to seconds_since_epoch * 1000. The ~25,200,000 difference is due to the naive datetime conversion. That's a 7 hour offset from GMT.

It seems that total_seconds() already gives the fractional seconds, so no need to add in microseconds.

While this doesn't make much difference for data points with second resolution, subsecond resolution results in shifting.

(i'll submit a patch if it isn't already fixed.)

Stack traceback and/or browser JavaScript console output

Screenshots or screencasts of the bug in action

[bryevdv]

Time zone issues should be handled at this point but a mailing list post recently noted the issue with the sub-second component. After a (very) brief look, it seems like the milliseconds component wa doubled which would be explained by the hypotheses above.

[bryevdv]

Thanks for the issue @clarsen Such a simple-to-fix issue should have been resolved immediately. I'd like to apologize that this somehow did not get triaged earlier (and hence was overlooked until now)

[clarsen]

no worries. Thanks :)

…

On Wed, Jan 3, 2018 at 3:22 PM, Bryan Van de Ven ***@***.***> wrote: Thanks for the issue @clarsen <https://github.com/clarsen> Such a simple-to-fix issue should have been resolved immediately. I'd like to apologize that this somehow did not get triaged earlier (and hence was overlooked until now) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6680 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC8ldkXStKOFxyqBrpchW75BJRa0FBuks5tHAvAgaJpZM4OkziN> .