timestamp to 12 hour readable time.

"sunrise":1508155906

I need this to something like 6:32am or whatever its suppose to be in arduino. I already downloaded a time library, but i'm arduino retarded apparently.

Which time library? And where did the timestamp come from? Usually a time library has API calls to do this conversion for you.

An issue you can run into is time zone. Epoch time stamps are usually all synced to the 0 meridian. So if you are not there you will have to adjust it to your timezone to get a local time.

--- bill

api.openweathermap.org and I have already determined from reading it its off by about 12 minutes. Not sure im liking this weather app.

prodigyrick: api.openweathermap.org and I have already determined from reading it its off by about 12 minutes. Not sure im liking this weather app.

which time library are you using?

I would think that their servers were using NTP so the time should very accurate.

You can use the Time library to do the conversion. https://www.pjrc.com/teensy/td_libs_Time.html But it doesn't support time zones. Timezone shifting is easy as you simply add/subtract the appropriate number to seconds to shift the timestamp to the local timezone. However, it gets complicated to know how to handle daylight savings time (summer time in EU). To do that you can add the Timezone library: https://github.com/JChristensen/Timezone

--- bill

So how would I read that timestamp? I installed those libraries. I'm in the Chicago timezone. I live in Farmington, MO. btw, its suppose to be 7:12 AM, but its behind and I have the longitude, lat correct for my area on this api. Depending how I look my area up, it can be all over the place with values.

prodigyrick: So how would I read that timestamp? I installed those libraries. I'm in the Chicago timezone. I live in Farmington, MO.

You already have the timestamp so there is nothing to read. It sounds like you are wanting the time in "human" local time form. For that you would use the Time library as it has API functions to do the conversion from epoch time to local time.

However, you are not at the meridian (UTC/GMT- London etc...) So if you want a local time that is based on you being in US central zone vs London, you have to offset the timestamp appropriately. Currently the offset is 6 hours or 21,600 seconds. But the offset will change on Nov 5 due to the daylight savings time change. You can automatically account for that change into the conversion by using the TimeZone library to do the conversion for you instead of doing it manually as it can auto detect when to add/subtract the hour based on how you configure the rules.

Read the information about the libraries and see the examples. It isn't difficult.

--- bill

Maybe we should step back a bit. What it is that you really wanting to do? (without any presumed solution)

--- bill

bperrybap: So if you want a local time that is based on you being in US central zone vs London, you have to offset the timestamp appropriately.

the openweathermap API also provides current UTC offset for your location...

BulldogLowell: the openweathermap API also provides current UTC offset for your location...

Does that include knowledge and accounting for any Daylight savings time shifts for the current location or is it just the base UTC offset for the location? (i.e. do you still have to calculate the daylight savings time shift yourself?)

--- bill

bperrybap: Does that include knowledge and accounting for any Daylight savings time shifts for the current location or is it just the base UTC offset for the location?

--- bill

Again, you can get the current UTC offset of your location. Naturally, that would include the adjustment for DST.

BulldogLowell: Again, you can get the current UTC offset of your location. Naturally, that would include the adjustment for DST.

Really? That wasn't the case in other APIs I've used, but if it is in this case, that is great as it makes the adjustment really simple.


Returning a UTC offset that includes the correct DST/summertime offset is a not an easy thing to do.

In order to do that there must be HUGE tables and somebody has to constantly adjust and correct them as keeping track of all the local time change rules around the world as well as the geographic boundaries involved for the exceptions is a VERY messy task as each local government entity is allowed to create its own rules that can differ from the offset for its longitude. i.e. a single city or state can chose to not do DST or choose to have a different tz offset than its neighbouring entities at the same longitude. Knowing the full geographic boundaries of that exception is messy and requires lots of data.

--- bill

bperrybap: Really? That wasn't the case in other APIs I've used, but if it is in this case, that is great as it makes the adjustment really simple.


Returning a UTC offset that includes the correct DST/summertime offset is a not an easy thing to do.

it is quite trivial... it is the difference between UTC and local time. The API can furnish both your local time based on the data in your call (city/zip) and UTC.

getting time zone affinities from municipalities seems sort-of mundane, particularly since generally States 1) pick one and 2) stay in it!

BulldogLowell: it is quite trivial... it is the difference between UTC and local time.

That assumes you have the UTC and local time. But if trying to actually calculate the local time, getting the correct offset is definitely not trivial when dealing with daylight savings time adjustments. i.e. if the device has GPS coordinates and UTC, trying to turn that into a local time for that location is not trivial since the local community gets to determine if/how/when any daylight savings/summer time adjustment is done.

The API can furnish both your local time based on the data in your call (city/zip) and UTC.

If that is the case great, but they must have some sort of crazy database that can map GPS coordinates (or cities) to get the appropriate DST rules to take that into account.

getting time zone affinities from municipalities seems sort-of mundane, particularly since generally States 1) pick one and 2) stay in it!

While that is generally true in the USA, it isn't always the case. And around the World things can be quite different.

And that is the point I'm making. If the API can provide an accurate local time, it must be able to take into consideration all the messy details of daylight savings time in various locations.

--- bill

bperrybap:
That assumes you have the UTC and local time.

which is exactly what the APIs provide.

bperrybap:
If that is the case great, but they must have some sort of crazy database that can map GPS coordinates (or cities) to get the appropriate DST rules to take that into account.

You enter the city or postal code, or a spot on the map and you get both. Daylight Savings and time zones are Political, not geographical, after all.

After all, what would be the point of using a weather API without getting to select your locality?

bperrybap:
And around the World things can be quite different.

yes, they could be… but they really aren’t. So, if they are changing, they are events that people know about well in advance. Let’s face it, governments don’t make emergency changes to their timezones! :wink:

bperrybap:
And that is the point I’m making. If the API can provide an accurate local time, it must be able to take into consideration all the messy details of daylight savings time in various locations.

If they can handle the “messy details” about the atmosphere’s pressure, temperature, ozone, humidity, pollution, windspeed, etc. outside your home, I think DST would be rather boring for these guys. :sleeping:

Using the APIs correctly make your concerns a tempest in a teacup.

BulldogLowell: which is exactly what the APIs provide.

You enter the city or postal code, or a spot on the map and you get both. Daylight Savings and time zones are Political, not geographical, after all.

The true Timezone offset from UTC is not really political. It is geographical based on longitude. Sometimes the REAL timezone line is moved around a bit by the politicians for various reasons. Daylight savings rules are purely political decisions.

But when trying to get from UTC to a local time you start with local geographical information. So I'm assuming that they attempt to map the local geographical information to their database for a lookup. While it probably works most of the time, I'm guessing it isn't correct 100% of the time.

After all, what would be the point of using a weather API without getting to select your locality?

Its been a while but when I looked at this a few years ago, I was looking at from a standpoint of automatically determining the locality. I wanted to get from GPS coordinates to a local time and it wasn't always possible. Even if using the Atomic clock signals from Colorado, which can tell if when DST in the USA starts, and you have access to UTC you still have to know if the local community uses DST. Sure, you could have a human manually pick and configure the locality, but I was looking for a solution that was GPS based and the device would automatically do it with no human intervention. Perhaps the API capabilities are better now.

yes, they could be... but they really aren't. So, if they are changing, they are events that people know about well in advance. Let's face it, governments don't make emergency changes to their timezones! ;)

It isn't that the DST rules are changing, it is that for a given longitude or a small geographic region it can potentially be different than the surrounding community. Say for example Las Vegas decides to do it's daylight savings timing differently then the rest of the state of Nevada, then based on the GPS location being inside the city limits of Vegas, the local time is different than just outside the city limits. Even though both locations are inside the same state. And if trying to automate this based on GPS locations, some entity has to have all that information stored and kept up to date to be able to get from a GPS location (or even a zip code) to the current local time.

If they can handle the "messy details" about the atmosphere's pressure, temperature, ozone, humidity, pollution, windspeed, etc. outside your home, I think DST would be rather boring for these guys. :sleeping:

Too funny. I completely agree.

--- bill

prodigyrick: "sunrise":1508155906

I need this to something like 6:32am or whatever its suppose to be in arduino. I already downloaded a time library, but i'm arduino retarded apparently.

Too many words, not enough figures.

1508155906 seconds converts to 17455 days, 12 hours, 11 minutes, and 46 seconds. So now you have the time of day you care about, namely 12:11:46. But that is Greenwich Mean TIme, which you will need to convert to your own timezone. I leave the rest to you.