I want to calculate the amount of seconds between 2 dates, but I'm getting a date that's not accurate
For example when I ran a macro with an action set to Calculation and then NOW()
I got a certain amount of seconds. When I do the calculation "manually" based on January 1, 1970, I get the date of tomorrow and then the time is not correct:
Midnight on January 1, 1970 where ?
(There are many time-zones worth of variation there – New Year corks pop in Sydney NSW before they do in Los Angeles CA)
You may need to allow for an offset to UTC
You're right. Forgot about that...
So how would I achieve that?
I'm in Portugal and it's 4:47pm now (UTC+00:00)
The Token %ICUDateTimeFor% will return the date/time in your locality for a UNIX time number.
UNIX Time to Local Time.kmmacros (3.3 KB)
Thanks for clarifying. I have an action that does that, but what if I want to keep the unix time format, in seconds?
I was working on a macro that needed that format instead of the format you converted it to
Well, I suppose keep everything in UNIX time throughout the Macro, until you need to show a result in a human readable format?
I think you'll need to use the ICUDateTimeFor token, which returns the specified date/time in the local time zone. I had to muck with this in my Upcoming Rocket Launches macro, so you could look at that to see what I did. It's a bit trickier than it should be, as you have to get the date and time into the right format before you can use the token.
-rob.
But what made me start this topic is because when I get the UNIX time and I check it against my local time, it's not accurate. For my current macro, it doesn't make a difference because I'm just calculating the time delta (@griffman look at me sounding smart and all that haha) so it's irrelevant if the value is accurate or not.
But if I needed it to show the actual amount of time in seconds based on my local time, it would be off.
I took a quick look, but I gotta be honest... it hurts my brain just looking at it, because of its complexity... 
This is way above my current knowledge, I'm afraid. Maybe one day I'll get there...
But for this macro I'm working on, the backup system, it's not relevant. To be honest, I don't know if I will ever need the UNIX time to be accurate.
I understand—of all the stuff in that macro, the time bit was the trickiest for me to figure out, as I'd never done much with time in my macros. Heck, figuring out how to parse the JSON was actually simpler, and I'd never done that before either :).
-rob.
I started using KM over a year ago, I guess, and even though I'm not a developer and I'm not comfortable with most languages out there, I can see how I improved my macros and my understanding on how things work while using Shell, AppleScript, RegEx, etc.
I mean, I can do some things with those and while doing some research now I can understand it a bit more, but still not something I'm comfortable with.
One step at a time and I take a lot of notes, save actions and groups of actions, so I'm learning one way or another. And I appreciate your time and help. It can be very frustrating sometimes not knowing how to get things done when you know they are probably super basic and easy
You sound quite similar to me—I'm not a developer and don't know how to write a full program in any language, with the exception of some simple shell scripts. About the only difference is that I started using KM so many years ago that I can't really remember :).
And I did things much as you're doing them: Learn one macro at a time, keep good notes, and read and post here when I get/got stuck. If you'd asked me when I started if I could ever write something like my macro backup tool or my web search tool, I'd have said "not a chance!" It's pretty amazing what KM can enable given time and dedication!
-rob.
Completely agree. It's been an interesting learning experience. Even for other things that are not related to KM. For example now that I learned a bit more of RegEx, I was able to install an Obsidian plugin to search using RegEx, which expands the capabilities of the app.
And yeah, maybe if someone who's starting now using KM looks at what I do, maybe they will have the same reaction, that it seems that I know "a lot" when in fact, I don't 
I mean, I'm "ok" with creating more complex macros, sometimes I have to rely on lengthy solutions that other would achieve using 1 action and 1 shell/AppleScript, but hey, sometimes if it works, it works. it's better to just move on instead of trying to save an extra second in a macro. Sometimes we spend more time on the forum trying to find the solution, than we would save in 10 years using a "messy" macro haha
It is accurate as UNIX time is the amount of seconds etc etc based on GMT which is now referred to as UTC (they are the same thing).
If you have a UNIX time in seconds for the start of something on your system and then you add say, 10 more seconds to that UNIX time that will be completely accurate in UNIX time no matter where you are in the world.
There is no inaccuracy, but there might be an offset to display the results in local time.
As @ComplexPoint pointed out, depending on where I am, it will influence that value.
Midnight Jan 1, 1970 was still Dec 31 1969 somewhere else, right?
So if X amount of seconds have passed for someone living in San Francisco since Jan 1 1970, the number of seconds for someone in Portugal (where I'm based) will not be the same value.
Being in Portugal, that's UTC / GMT so shouldn't the amount of seconds be accurate to show me the actual date? When I use a calculator for those seconds it gives me the values I shared on my screenshot.
I understand that if this was someone in a different time zone it would give a different result. But can you explain this? I'm really confused
It would still have been the same Unix time wherever you were in the world, but to display as local time it would have been + or - a certain amount.
So, in Portugal if you record the Unix time for an event, apply some maths to add say, an hour the result will be the correct Unix time. It won't be inaccurate. It would only be inaccurate if Portuguese time was going faster or slower than Unix time but it is not. It is running at the same speed with an offset if you want to display in local time.
My point is not that it's going faster or slower.
What seems to be established is this, based on this page:
"This count starts at the Unix Epoch on January 1st, 1970 at UTC"
This means that for example, at midnight Jan 1, 1970, in London, it was time "zero" and we start counting the seconds from there, right? So someone in London, if they do the math of that long number, it will give them the exact date and time.
So if I'm in Portugal and Portugal is UTC, when I do the math, shouldn't I get the exact date of today? Why am I getting the date of tomorrow, and it's not even 24 hours more, it's 12. Where are those 12 hours more coming from?
So which country/countries would have the accurate math calculation where converting the whole number would give the exact date and time?
It's like saying: ok I'm in this place, this will be the starting point (zero kilometers). Now I'm gonna walk 10KM. Then when I get there, I look at the meter and see 8.5KM.
Something is not making sense to me.
Did you try running the example Macro I uploaded? All it does is gets the current Unix time (which is the same wherever you are in the World) and then does the maths to show that in your local time.
If that is showing you the correct local time then maybe something is wrong in the maths you are doing to get a result that is out of step of what you are expecting?
I didn't, but I did now. I also have a similar macro and that is also accurate. So maybe the issue is with how Raycast is calculating this, which is what I was using in the screenshots.
But for example I tried adding 86,400 seconds, which is 24 hours to the same time yesterday, and I got the current date. So it's weird that when I get the number from UNIX, it gives me something else... go figure...
