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?
Stolen from the README:
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
about
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:
- express the local solar time value of interest in seconds from
local midnight
- convert the UTC time stamp to seconds from UTC midnight
- longitude shift the result of 2 to the local time frame
- 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:
- express the local solar time value of interest in seconds from local
midnight
- convert the UTC time stamp to seconds from UTC midnight
- longitude shift the result of 2 to the local time frame
- 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
in otherwords it needs to be expressed in the