Closed jbianchi81 closed 2 years ago
Some entries from the .csv seem odd, e.g., 393, 394. Otherwise, the elements could be mapped as follows: notation = offset name = offset description = timezone I personally think, it is more relevant to know the offset (in hours), rather than the timezone. It is also more easily managed. The problem is that several timezones exist for the same offset, so they should be listed together (the offset needs to be unique).
@amilan17 - create branch may not be ready for FT22-1
The problem of using offset as notation is that it wouldn't take into account offset changes due to daylight saving nor historical changes of rules.
I suggest using the list of tz database. It is a collaborative compilation of information about time zones, taking into account offset changes. It uses the naming convention area/location, i.e. Asia/Kolkata. Area is the name of a continent or an ocean. Location may be a compound name, resulting in a 3-level name, as in America/Indiana/Indianapolis. Special area Etc is used for administrative zones.
There are numerous implementations of this database, including python libraries tzinfo and pytz. I also found that the library tzwhere may be used to assess if a given geographical location belongs to a specific timezone, i.e.:
import pytz
from tzwhere import tzwhere
tzwhere = tzwhere.tzwhere()
def is_within_timezone(lon,lat,tzid):
if tzid not in pytz.all_timezones:
raise ValueError('timezone not found in code list')
timezone_str = tzwhere.tzNameAt(lat, lon)
if timezone_str != tzid:
raise ValueError('coordinates don\'t match timezone')
return True
I have no issue with the use of the official IANA tz database as the source of a code list for WMDR, but I think the purpose of this code list is different in our case. We are not interested in mapping a time zone like 'Switzerland/Berne' to a UTC offset like '+1'. We are interested in documenting the UTC offset of a station itself. In particular, daylight saving time does not matter because all observations should be referenced against UTC. So, in my view, the codelist should indeed take the form I suggested earlier, perhaps with a slight adaptation, cf.
notation = offset name = UTC+offset description = Examples: list a few typical timezones
specifically, by way of examples
notation | name | description |
---|---|---|
-6 | UTC-06:00 | Timezone with a UTC offset of -06:00 hours. Locations in this timezone include America/Costa_Rica, America/New_York, Canada/Mountain, Mexico/BajaSur, Pacific/Galapagos |
5.75 | UTC+05:45 | Timezone with a UTC offset of +05:45 hours. A location in this timezone is Asia/Kathmandu |
9.5 | UTC+09:30 | Timezone with a UTC offset of +09:30 hours. Locations in this timezone include Australia/Adelaide, Australia/North, Australia/South, Australia/Darwin |
Sounds good to me. Also the list will be shorter. It would be like this: https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
@fstuerzl Do you think you could create this table and add it to the branch? The link in the Proposal doesn't seem to resolve to such a table.
@joergklausen @fstuerzl If you agree, I could generate the table with a script, update the Proposal and share the script
Discussion on the form of the notation: signed decimal number vs a more comprehensive form of UTC+hh:mm; to be discussed. @jbianchi81 Thanks for creating the branch
@jbianchi81 -- will you have time to update this branch before our next meeting? We'd like to have this ready for FT22-2 before the end of May.
@amilan17, @joergklausen : Proposal and branch updated.
https://github.com/wmo-im/wmds/wiki/2022-05-19-TT-WIGOSMD-22 notes:
@joergklausen -- ready for validation
@joergklausen @jbianchi81 - Is 4-08 an appropriate table ID for this type of table? Category 4 of the WIGOS Metadata Standard is for describing the geographical environment of the station. Furthermore, I think there are other places in the standard that might reference the TimeZone codelist (see https://github.com/wmo-im/wmdr/issues/23).
Table number could be 11-03 just as well.
https://github.com/wmo-im/wmds/wiki/2022-05-31-TT-WIGOSMD-23 notes:
@amilan17 update table number and move to ready for FT
ready for FT
Summary and Purpose
According to https://schemas.wmo.int/wmdr/1.0/html/ TimeZone property of observingFacility is defined by a reference to a code list, which is missing on codes.wmo.int/wmdr.
Proposal
The current proposal includes the following fields:
Source: <https://www.iana.org/time-zones> last version 2022a (released 2022-03-15)
The script for generating this table can be found here. For now, the description includes all locations found for each timezone. These enumerations should be shortened by selecting the most representative locations.
The table was added to the branch as 4-08.csv.
Reason
[your reasoning why the proposal resolves the issue]