# Solar local time

i’m working on a sticky issue: i’m converting some times based on a utc
time
and longitude - the goal is the express the time as solar local time.

the code i have is close. it does something like:

`````` DEG_PER_HR = 15.0
SECS_PER_MIN = 60.0
SECS_PER_HR = SECS_PER_MIN * 60.0
SECS_PER_DAY = SECS_PER_HR * 24

# longitudes > 180 degrees are behind UT
# longitudes <= 180 degrees are ahead of UT

offset_seconds =
if longitude > 180.0
- ((360.0 - longitude) / DEG_PER_HR) * SECS_PER_HR
else
(longitude / DEG_PER_HR) * SECS_PER_HR
end

utc + offset_seconds
``````

this in fact yields the correct time except that’s it’s expressed in
zulu
time and not the ‘local’ time zone. the trick is that ‘local’ here
means
‘there’ not ‘here’! in otherwords it needs to be expressed in the
local
time zone of that longitude not mine and not that of greenwich.

to put it more consisely i need to be able to follow

locatime_but_in_utc = utc + offset_seconds

with

move_to_zone locatime_but_in_utc, longitude

or some other viable alternative.

thoughts?

-a

On Aug 8, 2006, at 2:23 PM, [email protected] wrote:

``````SECS_PER_HR = SECS_PER_MIN * 60.0
end
``````

time zone of that longitude not mine and not that of greenwich.

thoughts?

Does TZInfo bring you closer?

Note that the Time returned will look like it is UTC (Time.zone
will return “UTC”). This is because it is not currently possible to
change the offset of an individual Time instance.

On Wed, 9 Aug 2006, Logan C. wrote:

tz = Timezone.get(‘America/New_York’)
local = tz.utc_to_local(Time.utc(2005,8,29,15,35,0))

Note that the Time returned will look like it is UTC (Time.zone will return
“UTC”). This is because it is not currently possible to change the offset
of an individual Time instance.

nope. timezones are politicalized solar local times. basically i’m
searching
a polar orbiting satellite data set for scanlines where the localtime is
7 am. it sounds easy - it’s near impossible.

-a

On 8/8/06, [email protected] [email protected] wrote:

`````` SECS_PER_DAY = SECS_PER_HR * 24
``````

locatime_but_in_utc = utc + offset_seconds

with

move_to_zone locatime_but_in_utc, longitude

or some other viable alternative.

thoughts?

ZONES = class << Time; ZoneOffset.keys.map {|x| x.length == 1 ? x :
nil}.compact.sort; end
ZONES.unshift ZONES.pop

def move_to_zone( utc, longitude )
zone = ZONES[Integer(longitude) / Integer(DEG_PER_HR)]
utc - Time.zone_offset(zone)
end

This does not take into account daylight savings, etc. But give it a
shot and see if it’s what you need.

TwP

On 8/8/06, [email protected] [email protected] wrote:

snip

with

move_to_zone locatime_but_in_utc, longitude

Clarification question … do you want the returned value to be a
Float or an actual Time object?

TwP

PS Maybe I should have asked this before posting my little solution
there

On Wed, 9 Aug 2006, Tim P. wrote:

Clarification question … do you want the returned value to be a
Float or an actual Time object?

TwP

PS Maybe I should have asked this before posting my little solution there

i’m starting to think it has to be a float… but a time would be
better.

-a

On Wed, 9 Aug 2006, Tim P. wrote:

shot and see if it’s what you need.
it’s close, but check this out:

`````` harp:~ > cat a.rb
require 'time'

class Time
ZONES =
class << self
(_ = ZoneOffset.keys.select{|z| z.size ==
``````

1}.sort).unshift(_.pop)
end
def translated longitude
zone = ZONES[Integer(longitude) / 15]
utc - Time.zone_offset(zone)
end
end

`````` t = Time.parse('1999-12-31T23:59:59Z') or 'party like it is'

require 'yaml'

[0, 15, 16, 30, 31].each do |degrees|
y degrees => t.translated(degrees).iso8601

y -degrees => t.translated(-degrees).iso8601
end

harp:~ > ruby a.rb
0: "1999-12-31T23:59:59Z"
0: "1999-12-31T23:59:59Z"
15: "1999-12-31T22:59:59Z"
-15: "2000-01-01T11:59:59Z"
16: "1999-12-31T22:59:59Z"
-16: "2000-01-01T10:59:59Z"
30: "1999-12-31T21:59:59Z"
-30: "2000-01-01T10:59:59Z"
31: "1999-12-31T21:59:59Z"
-31: "2000-01-01T09:59:59Z"
``````

take one example

`````` 15: "1999-12-31T22:59:59Z"
``````

the time is correct but the zone is not. consider, 15 degrees to the
east of 0
longitude at ‘1999-12-31T23:59:59Z’ the solar local time is

`````` '1999-12-31T22:59:59+01:00'
``````

make sense?

-a

If I understand the problem you describe (likelihood estimate ~ 50%),
it’s similar to a telemetry data problem I once worked on. Here is
how I handled it:

1. express the local solar time value of interest in seconds from
local midnight
2. convert the UTC time stamp to seconds from UTC midnight
3. longitude shift the result of 2 to the local time frame
4. compare result of 1 and 3 to determine whether or not to process
further

Maybe you could adopt a similar approach.

Regards, Morton

On Wed, 9 Aug 2006, Morton G. wrote:

If I understand the problem you describe (likelihood estimate ~ 50%), it’s
similar to a telemetry data problem I once worked on. Here is how I handled
it:

1. express the local solar time value of interest in seconds from local
midnight
2. convert the UTC time stamp to seconds from UTC midnight
3. longitude shift the result of 2 to the local time frame
4. compare result of 1 and 3 to determine whether or not to process further

yes. i’m thinking of something similar - perhaps returning a fraction
(of the
current day) or something similar. the reason i was trying to stick
with time
objects is to make calculations easier…

it’s damn tricky though.

-a