Skip to content

ts_created/updated/.../ now is bigint. - #14

Open
crchemist wants to merge 4 commits into
scionrep:masterfrom
crchemist:ts_created_refactored
Open

ts_created/updated/.../ now is bigint.#14
crchemist wants to merge 4 commits into
scionrep:masterfrom
crchemist:ts_created_refactored

Conversation

@crchemist

Copy link
Copy Markdown
Contributor

With this patch we able to sort farms by date 😄

@mmeisinger

Copy link
Copy Markdown
Contributor

This is a big change of the framework persistence format. The change looks good but I need to investigate it in detail to check for unintended side effects.

Did you check the application with this version to see if it works all fine? Do all tests pass?

@crchemist

Copy link
Copy Markdown
Contributor Author

@mmeisinger all scioncc/pyon and scioncc/ion tests pass, our application tests also pass.

@mmeisinger

Copy link
Copy Markdown
Contributor

I'm still reviewing this change and all consequences on system and app timestamps, messaging, database persistence etc. There are a few issues with this PR in the use of int/long (note that on 64bit systems, Python int has 64 bit, so type long is not necessary - also Python automatically overflows to long from an int). I would also like ScionCC YML to be language independent, not specific to Python.

Note that string timestamps can indeed be sorted nicely, because all times since Sept 2001 are 13 chars long until far beyond year 2286 and thereby sort in string order. Only time values before 2001 have fewer chars and therefore do not sort. For system timestamps this should be a non-issue, given that ScionCC was published 2014 and all create/update timestamps will be after a system start.

For user dates (e.g. birthdates, etc) a different time representation should probably be used, e.g. an 8 byte float such as in Python, which should provide microsecond accuracy for many decades and has no limit in the range of years that can be expressed. Or even better an ISO8601 string in the form "2011-10-10T14:48:00", which can be parsed and generated by Python, JavaScript etc. and also supports timezone information and fractional seconds as needed, e.g. "2011-10-10T14:48:00.123456+01:00"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants