1

I am having a hard time to convert local solar time to UTC for MODIS data.

According to the Users' Guide of the product (MOD11A1 Product - Wan Z., 2013), local solar time given for each pixel is

"the UTC time plus grid’s longitude in degrees / 15 degrees (in hours, +24 if local solar time < 0 or -24 if local solar time >= 24)".

Should we take into account the day of year when calculating the UTC time although it is not mentioned in the instruction provided above?

I am using Google Earth Engine, code editor with Javascript.

0

2 Answers 2

3

There are two ambiguities, one in the definition and another one in the name used, for that data.

In the name because it does not distinguish between true and mean sun, although its definition corresponds to the mean solar time.

In the definition because it says in hours, it doesn't say in decimal hours or in whole hours.


Solar time is always local (UTC is the reference meridian's mean sun time measurement), because the index is always a meridian plane. Other scales of time change the star reference, but not the index.

Mean solar time is the hour angle of the mean sun, plus 12 hours. This definition is coincident with the formula: MST = UTC + longitude. Also, it makes sense that the satellite can determine that angle for each pixel (and if the value is true solar time, I would believe it more, and I regret that ambiguity) and does not need to be synchronized with Earth time.

About time zones, which could be inferred by assuming whole hours in the definition: Astronomical determinations and arguments were never related to time zones, and the definition does not mention them. For civil life, it is not practical for our time to vary continuously with each step we take to the East or West, when in fact that is what's going on.


Therefore, I am inclined to think that the UTC time of the observation should be calculated directly as the subtraction between the local solar time value and its corresponding longitude, converted to decimal hours. At least, the definition satisfaces that idea.

2

Following script will be used to review some concepts. It employs MODIS product considered in Wan, Z. (2013) reference. After running the script, it adds only one image of that series (number 5) selecting "Day_view_time" band.

var dataset = ee.ImageCollection('MODIS/006/MOD11A1')
                  .filter(ee.Filter.date('2018-01-01', '2018-05-01'));

var collection = dataset.limit(5)
  .select("Day_view_time");

var list = collection.toList(collection.size());

print(list);

var image = ee.Image(list.get(4));

print(image);

var parVis = {
  min: 100,
  max: 120,
  palette: ['040274', '0602ff', '32d3ef',
            'fff705','de0101', 'c21301', 
            'a71001', '911003']
};

Map.addLayer(image, parVis, 'image');

// Get the timestamp and convert it to a date.
var date = ee.Date(image.get('system:time_start'));
print('Timestamp: ', date); // ee.Date

Added layer can be observed in following image, where it was also clicked in an arbitrary point situated in USA area and this event recorded in Inspector Tab.

enter image description here

If you observe Table 9 of Wan, Z. (2013) article, scale factor is 0.1 for this band. So, local solar time in this point (-97.795, 34.55) is 112*0.1 = 11.2 h = 11 h 12 min.

If you want to calculate UTC Offset Standard Time: longitude in degrees / 15 degrees = int(-97.795/15) = -6 h. However, USA also has UTC Offset Daylight Saving Time. In this case, it is necessary to watch date printed in Console Tab: Date (2018-01-05 00:00:00). It corresponds to Daylight Saving Time so, UTC Offset is -5 h.

Finally, for calculating UTC time for this image:

UTC - 5 = 11.2, UTC = 11.2 + 5 = 16,2 = 4:12 PM.

Complete date for this image with UTC time, in that point, it would be:

Date (2018-01-05 16:12:00)

and with local solar time:

Date (2018-01-05 11:12:00)
4
  • Thanks for much detailed answer! Two questions regarding it; -My aim is to convert the local solar time information to UTC as precise as possible. So in your example, -97.795/15=-6.52h would give an offset of - 6h 31min. Am I correct? - And in terms of daylight savings, to my knowledge UTC time is not affected by the daylight savings, it remains the same. Therefore shouldn't the offset be 6h in your example regardless of the season and the daylight savings?
    – user146783
    Mar 21, 2020 at 15:59
  • 1
    Hi xunilk, I also consider strange the conversion of the meridian to the local time zone, being that the data is defined in solar time. Time zones have a practical use in civil life, but astronomical arguments are not usually conditioned by them. Mar 21, 2020 at 19:27
  • Hi @xunilk and Gabriel De Luca. I understand that in a standard case, we should take into account the daylight saving time when converting from local solar time to UTC. But according to the instructions provided by the product, I am still not 100%sure, but more inclined to think that maybe a direct relationship between local solar time and UTC should be established as instructed without considering season/day of year/ daylight saving time etc.. Like Gabriel De Luca described above "11.2 hs = UTC + (-6.52) hs, UTC may be (11.2 + 6.52) hs..."
    – user146783
    Mar 21, 2020 at 22:03
  • Hi @xunilk, I believe what you mention is based on the relationship between local time and UTC time. UTC time itself does not change depending on season, it does not have a daylight saving time adjustment. The local times change with daylight savings time. The local time where you live is UTC-4h at this time of year, and again the local time will be UTC-3h during the daylight saving period.
    – user146783
    Mar 22, 2020 at 1:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.