UnixTime conversion

Create issue
Issue #690 open
Former user created an issue

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)

  1. Jean-Michel Frouin

    @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 ?

  2. Jean-Michel Frouin

    Humm all code use Quantity ... it will be a big work to add Date ... and maybe it's not a good idea ... no ?

  3. Philip Federici

    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.

  4. Jean-Michel Frouin

    Quantity is a class / object use a lot in source code.

    Your idea is simpler to implement :) I will make a try :)

  5. Tey'

    @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 like YYYY MM DD.hh mm ss).

  6. shirish agarwal

    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.

  7. Jean-Michel Frouin

    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.

  8. Jean-Michel Frouin

    @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.

  9. DrFrankenstone / Treer

    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?

  10. Log in to comment