Hi Chris,

I think I've found an issue to do with time zones. When calling Solar with my lat/long (latitude: -38.2613, longitude: 145.1896), the returned date is always one day ahead of the for-date for all times (sunset, sunrise, all modes). Also, daylight savings is not being processed for my timezone (Melbourne, Australia)

I think the day-ahead problem may stem from line 188;

let localT = UT + (Double(timeZone.secondsFromGMT) / 3600.0)

as this pushes the "hour" variable in the following line;

let hour = floor(localT)

into numbers between 24 and 48 (i.e. the next day)

I tried fixing this up by putting the hour back into 0-24 hour range, but this mucked up the minute and second calculations. So, I had a think about timezones and went back to the underlying returned NSDate being an absolute number of seconds, regardless of timezone and that all your calculations were for UTC time. Given this, I (hack) changed line 188 to do nothing as follows;

let localT = UT

and replaced line 199;

var date = calendar.dateFromComponents(components)

with;

calendar.timeZone = NSTimeZone(abbreviation: "UTC")!
return calendar.dateFromComponents(components)

By changing the the time zone to suit your calculated UTC time, the returned NSDate will be the correct absolute number of seconds and any code using the returned NSDate will have the appropriate timezone set. This means the time zone calculations for the calling apps purposes will all be handled by the Swift libraries. As a side effect of getting the day correct, this also fixed up the issue where daylight savings was not being handled correctly.

NB: the early return I added in line 200 intentionally means lines 202 onwards are not called as they are no longer required.

I tested this fix for both Melbourne, Australia and London, England. It got the correct day, time and daylight savings was processed correctly. What do you think?

Cheers, Graham.

SPM support for the library. I have changed the sample json file to use multilane string to be compatible with sim prior swift 5.3 (resources). Both Carthage and pods version are still supported. SPM package contains passing tests and I have defined other supported platforms iOS(.v8), .macOS(.v10_15), .watchOS(.v4), .tvOS(.v11)

Fixes #11.

There is error when I adding Solar to my project with carthage and hope you can check it out :) log: *** Fetching Solar *** Checking out Solar at "2.0.0" *** xcodebuild output can be found in /var/folders/0m/bv501p9j043_w386gf5g7dlh0000gn/T/carthage-xcodebuild.vDSKOj.log *** Building scheme "Solar" in Solar.xcodeproj Build Failed Task failed with exit code 65: /usr/bin/xcrun xcodebuild -project .../Carthage/Checkouts/Solar/Solar.xcodeproj -scheme Solar -configuration Release -derivedDataPath /Users/brucewzp/Library/Caches/org.carthage.CarthageKit/DerivedData/Solar/2.0.0 -sdk iphoneos ONLY_ACTIVE_ARCH=NO BITCODE_GENERATION_MODE=bitcode CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES clean build

This usually indicates that project itself failed to compile. Please check the xcodebuild log for more details: /var/folders/0m/bv501p9j043_w386gf5g7dlh0000gn/T/carthage-xcodebuild.vDSKOj.log

official sunset today (2/12/17) was 5:45 pm in San Francisco. The isNighttime method returned true at 5:31 pm.

I believe this is because it's using Date() without a time zone to calculate when sunset is. However, in Pacific timezone, it is already reporting GMT sunset for 2/14

I get the following build warning when building with Xcode 12.5:

/Users/me/Library/Developer/Xcode/DerivedData/Project/SourcePackages/checkouts/Solar/Package.swift The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 14.5.99.

This appears to have been fixed for Solar.podspec by 07e6310. Solar's Package.swift was likely overlooked. Please update the Package.swift deployment target to be consistent with the Solar.podspec.

Only build the test bundle as part of the Solar scheme when building for test. Removed the SolarTests scheme, which is redundant.

Fixes #21.

/cc @ceeK @bsudekum

Hi Chris,

Thank you loads for the work porting the calculations to Swift, it's been very helpful!

In testing I found the sunset times for offical, civil, etc., were all the same. In Solar.swift on line 162, I noticed the calculate function was not using the passed-in zenith and was instead always using the "Official" zenith;

   let cosH = (cos(Zenith.Official.rawValue.degreesToRadians) - (sinDec * sin(latitude.degreesToRadians))) / (cosDec * cos(latitude.degreesToRadians))

This can be corrected with the following;

   let cosH = (cos(zenith.rawValue.degreesToRadians) - (sinDec * sin(latitude.degreesToRadians))) / (cosDec * cos(latitude.degreesToRadians))

Cheers, Graham.

Updated the Xcode project, CocoaPods podspec, and readme for v3.0.0. This is a major version because of #53 #55, which increases the minimum iOS deployment target.

Added a Solar-dev podspec that I’m planning to push to CocoaPods trunk. Initially it’ll be a workaround for #51, but we can treat it as a way to distribute prereleases in the future.

/cc @MaximAlien @ceeK

After updating Xcode to version 10, it shows me the following error on import Solar: Module compiled with Swift 4.1.2 cannot be imported by the Swift 4.2 compiler. Any ideas how to fix this?

Would you consider adding sun position information to this library, i.e. altitude and azimuth? See the docs at https://github.com/mourner/suncalc for an example. Feel free to close this issue if it's out of scope.

Updated the Xcode project (using agvtool), CocoaPods podspec, and readme for ~~v2.3.0~~ v2.2.0. Also updated copyright statements for this year. A draft GitHub release has been prepared.

@ceeK, I’ll need your help to push ~~v2.3.0~~ v2.2.0 to CocoaPods trunk once this PR lands (or I can do it if you make me a co-owner of the pod). Thanks!

WeatherKit has a CurrentWeather.isDaylight property and SunEvents struct that essentially replicate the functionality of this library. However, WeatherKit is only available for this year’s operating system releases (iOS 16, iPadOS 16, macOS 13, tvOS 16, watchOS 9). Should this library somehow integrate with WeatherKit on supported platforms, perhaps becoming a compatibility shim for it on unsupported Swift platforms like Linux?

For places where there's a polar day in the given time/date (see the example), isDaytime returns false and isNightTime returns true for all times of day (just opposite to reality).

Code:

private func isSunUp(dateTime: Date, coords: LatLon) -> Bool {
    let solar = Solar(for: dateTime, coordinate: CLLocationCoordinate2D(latitude: coords.lat, longitude: coords.lon))
    return solar!.isDaytime
}

Params: dateTime: 2022-06-03 06:00:00 +0000 coords: lat: 67.94753132376813, lon: 13.131613209843637

Fixes #40

This issue appears if the date/time given to calculate is already "tomorrow" at UTC. For example, I'm in New York City, which is GMT-5. If I calculate between 00:00 - 18:59 hrs local time, I get a correct result. But if I calculate 19:00-23:59 local time, Solar return's tomorrow's result. A test is included in this PR to demonstrate.

To fix, I added an optional timezone: parameter to Solar(). If timezone is not specified, UTC is assumed. This makes the patch backwards compatible. If timezone is included, the current time (in seconds) is offset by the time different between local and UTC. This ensures the calculations are done on the correct date, and not possibly "tomorrow's" date.

Resubmitted from #44

Fixed the following scenario.

When Sunrise timing is 2300 while current time is 2330, isDayTime wrongly shows false. When sunset timing is 0050 while current time is 0030, isDayTime wrongly shows false.

It seems that the dates are 1 day in the future if the local time is the next day UTC.

Not sure if this is the same problem as reported in #24?

Here is a complete test. Note that the reported times are one day in the future from the correct times.

    ///    Sun and Moon Data for One Day
    ///
    ///    U.S. Naval Observatory
    ///    Astronomical Applications Department
    ///
    ///    (Longitude W 94° 0', Latitude N 39° 0')
    ///
    ///    Friday, May 3, 2019    Universal Time - 5h
    ///    Sun
    ///    Begin civil twilight    05:47
    ///    Sunrise    06:16
    ///    Sun transit    13:13
    ///    Sunset    20:11
    ///    End civil twilight    20:40
    ///    Moon
    ///    Moonrise    05:56
    ///    Moon transit    12:24
    ///    Moonset    19:00
    ///
    /// [https://aa.usno.navy.mil/data/docs/RS_OneDay.php](https://aa.usno.navy.mil/data/docs/RS_OneDay.php)
    func testPlainLatLon() {
        var tdf: DateFormatter = {
            let df = DateFormatter()
            df.dateFormat = "MM/dd/yyyy HH:mm zzz"
            return df
        }()
        let testCriticalEvening = tdf.date(from: "05/03/2019 19:20 CDT")!
        let testLocation: CLLocation = CLLocation(latitude: 39.00, longitude: -94.0)
        let expectedSunrise = "05/03/2019 06:16 CDT"
        let expectedSunset = "05/03/2019 20:11 CDT"
        let solar = Solar(for: testCriticalEvening, coordinate: testLocation.coordinate)

        XCTAssert(tdf.string(from: solar!.sunrise!) == expectedSunrise,
                  "Expected: \(expectedSunrise), Received: \(tdf.string(from: solar!.sunrise!))")
        XCTAssert(tdf.string(from: solar!.sunset!) == expectedSunset,
                  "Expected: \(expectedSunset), Received: \(tdf.string(from: solar!.sunset!))")
    }

The results of the test are:

UI Test Activity: 
Assertion Failure: Solar_iOSTests.swift:198: XCTAssertTrue failed - Expected: 05/03/2019 06:16 CDT, Received: 05/04/2019 06:14 CDT

UI Test Activity: 
Assertion Failure: Solar_iOSTests.swift:200: XCTAssertTrue failed - Expected: 05/03/2019 20:11 CDT, Received: 05/04/2019 20:11 CDT