UnixTime conversion
It would be usefull to convert UnixTime.
datetime(1482246078)
2016/12/20 15:01:18
unixtime(2016/12/20 15:01:18)
1482246078
Comments (16)
-
repo owner -
@Teyut or @heldercorreia this one could be useful for me too, can I try to implement :
- datetime(unix_timestamp)
- unixtime(date)
Maybe we need to find a better name for unixtime function ?
Maybe we can find a better name for unixtime ?
-
Humm all code use Quantity ... it will be a big work to add Date ... and maybe it's not a good idea ... no ?
-
I am not a developer. I am not sure if by "Quantity" you simply mean quantity or something specific. But if the former is the case, why not just make it a function with six arguments, as in:
unixtime(YYYY;MM;DD;hh;mm;ss) = n
e.g. unixtime(2016;12;20;15;01;18) = 1482246078
And the reverse case, if even feasible, could be an arbitrarily compiled number, that the user would know how to interpret, as in:
datetime(1482246078) = 20161220150118 or 20161220.150118
for YYYYMMDDhhmmss or YYYYMMDD.hhmmss
It's not very elegant though.
-
Quantity is a class / object use a lot in source code.
Your idea is simpler to implement :) I will make a try :)
-
Happy to have been somehow useful whilst embarrassing myself. :)
-
- attached datetime.patch
Here is a patch which add datetime function. I cannot but a branch for PR. (I miss something ?)
Example: datetime(1538242871) return 20180929,194111
-
@jmfrouin Thanks for your contribution, but please, make a PR so that it's easier to review and discuss your changes. In order to make a PR, you need to fork this repository in your own bitbucket account, create a branch (recommended), make your changes there, then post a PR to your fork parent (this repository). Have a look at the example given here for the details.
A few comments about your patch:
- it is inverted (it cancels your changes instead of applying them)
- it misses unit tests (check
tests/testevaluator.cpp
). Since the result depends on the timezone, you'll probably have to set one in the test module so that the tests won't fail for people with different timezones. - translations are provided through transifex, so the related changes will be erased when we'll update the language files
- maybe you can add an optional timezone argument (as number), which would default to the local timezone
- the result won't be the one expected when the calculator is in hex/oct/bin and some decimal modes. I guess results should be associated to a specific unit (to be created) in order to have a static formatting (to be made).
I doubt we'll be able to format the result as something like
YYYY/MM/DD hh:mm:ss
(or take such inputs) as imagined by the OP, so the format proposed by @PhilipFederici is probably the only way we can have a meaningful output (or input). It might be possible to add digit grouping separators between each components though (something likeYYYY MM DD.hh mm ss
). -
Thanks for your comment, I will do that :) !
-
it would be nice to have it in DDMMYY but that's just me. Have been following the conversation from day 1. I don't have anything to contribute except the fact it would be nice if speedcrunch has his feature in it as well.
Maybe it could be in the configuration file or somewhere how the result of conversion should look depending on user's preference.
-
I will take a look of this calculator mode (hex/oct/bin and decimals modes), when this will be clear, I will try to make a setting for that, if possible.
-
@Tey' I make a branch (datetime) on my own fork of speedcrunch, with all your suggestions. The only one I didn't understand, or found how to implement, yet, is :
"the result won't be the one expected when the calculator is in hex/oct/bin and some decimal modes. I guess results should be associated to a specific unit (to be created) in order to have a static formatting (to be made)."
Especially the Specific unit to be created or static formatting. But I will look later.
I will make a PR so you can comment my code and maybe gimme some clue for this.
-
repo owner - changed milestone to 1.0
-
repo owner - changed status to resolved
-
This issue was half implemented - calendar calculations aren't possible if you can only convert from unixtime but not to it. Should the status have been changed to resolved?
-
repo owner - changed status to open
- Log in to comment