Talk:TIMZON
DavidAcland 17:31, 26 January 2012 (UTC): I have a slight difficulty with this because I imagine that the geography for this will the slices of the world shown on Time Zone charts.
There are two points.
1. These charts are normally a Mercator projection. I suggest that we cut off the tops and bottoms of the slices at say 84 or 85 degrees North and South because few nautical charts extend further.
2. The time zones cover many jurisdictions and often different time communities. There are two major communities using Time Zone A: Central Europe and Western Africa. It is almost certain that the Summer Time start and stop will be on different dates; probably about 6 months apart in the examples I have given. Similarly Western Australia and China (UTC+8) will probably have reversed summer times. Also have a look at the slice from Finland to South Africa. Here is a link to a Time Zone Chart http://www.igooglemaps.com/gfx/map_of_timezones.jpg
The definition for Time Zone at the moment is more or less OK. However we cannot apply a SMTOFF for the whole longitude slice. So it seems to me that we need a new definition which is for a more local geography and which will probably separate the N and S hemispheres with the exception of a few areas around the equator; and the equatorial zones may not have summer time anyway. At the moment I therefore think that we do need most of the Time Zones in Jens' tables (but remove the Summer Time element) and that my construction for CATZON is incorrect.
See also my comments at Talk:CATTZN.
raphael 21:35, 26 January 2012 (UTC): How about deleting "more or less bounded by lines of longitude" from the definition?
Encoding the time zones in Jens' list is OK, with or without summer time (if "with", we may not need the summer time attributes). The list might have to be updated if and when there are changes, which might be more often than we expect, because regions do change time zones or summer time now and then - on a worldwide basis, it seems to happen quite frequently.
There is a time zone database maintained by the IANA at http://www.iana.org/time-zones
Encoders will have to be careful about what polygons they define for time zones, because of (1) the summer time issues David mentions, and (2) the time zone maps I have seen do not show maritime boundaries.
jens 10:30, 27 January 2012 (UTC) I agree with Raphael's comment. Another definition can be "a geographic region within which the same standard time is used"
which is provided by http://www.merriam-webster.com/dictionary/time+zone
That would also be a good reference for the definition.
I also like the idea to simply define the value for the time zone and not the name. I assume the updates are not so frequent in that case. It is likely that we have to change the geometry for a time zone but not the time zone value itself.
raphael 18:27, 27 January 2012 (UTC): I like the Merriam-Webster definition too.
DavidAcland 12:01, 30 January 2012 (UTC) Thank you for your inputs. I shall start work as follows:
Change the definition as indicated above. This means we have solved the North South problem for land areas because the geometry associated with a time zone is not an entire longitude slice.
Looking at Larry Bennet's master paper version of ALRS Vol 2, I see that this subject is actually quite dynamic with tens of corrections in the Legal Time section each year. Larry also tells me that some countries report changes quite late; i.e. only a few weeks before the change takes place.
This section also shows entries by "Territory" with some nations divided into multiple territories. There are 11 territory entries for Russia which covers 11 time zones. There are about 300 territories listed. I am beginning to think that, rather than CATTZN carrying the name of the territory or time zone (Central European time: Eastern Standard Time), we should put that in the OBJNAM, carry the difference from UTC in CATTZN (-2; +8) and the offset for Daylight Saving Time in SMTOFF.
I think SMTSTA and SMTEND will need a complex structure because they are often a variable date, but sometimes a fixed date, and a time element along the lines of "Last Sun in Oct 0200h LT". I will see if we can reuse FIXDAT and VARDAT.
I have amended the definition of FIXDAT to make it more generic and useable for this purpose.
With a larger resdesign, including changing their names, we can also amend "timeStartofWork" TIMSTW and "timeEndOfWork" TIMENW. My proposal is to change these to "timeStartofSomething" TIMSTS and "timeEndofSomething" TIMENS, which I admit is a bit lame, but I cannot think of anything better. Other synonyms such as era, epoch, phase, interlude, stage do not sound any better. "TimeStart" would be fine but is already used by S-57. So with these changes we would have a generic way of encoding the start and end days and the start and end times, which could be used both for the working day and Daylight Saving Time periods.
So my structure would be;
TIMZON
OBJNAM Eastern Standard Time (Mandatory)
CATTZN +5 (Mandatory)
SMTSTA (populate either FIXDAT or VARDAT) Optional
FIXDAT
VARDAT Second sunday in March
TIMSTS (TIMDAY - proposed below) 0200 Mandatory
TIMREF=2 (LT) Mandatory
SMTEND (populate either FIXDAT or VARDAT) Optional
FIXDAT 30 Sep
VARDAT
TIMENS (TIMDAY - proposed below) 0200 Mandatory
TIMREF=2 (LT) Mandatory
SMTOFF +1 Optional
Any comments please?
raphael 17:59, 30 January 2012 (UTC): I think it is not necessary here to define distinct attributes TIMSTW and TIMENS. A single attribute for TimeOfDay (TIMDAY? DAYTIM?) should suffice. Whether it is a sub-attribute of SMTSTA or SMTEND indicates whether it is the start or end of summer time.
Some basic questions:
- Is it necessary to define a model which allows specification of the time zone at each point in navigable waters worldwide? Would it suffice to encode nautical standard time zones using longitudinal slices and say that territorial waters legal time supersedes nautical standard time?
- How much effort will it take to define the boundaries of TIMZON objects?
raphael 14:45, 31 January 2012 (UTC): On new names for TIMSTW and TIMENW: Something to do with "interval" or "duration"? INTSTA/INTEND? DURSTA/DUREND?
DavidAcland 19:45, 31 January 2012 (UTC) TIMDAY? Yes! And if we do this, there is no need to amend TIMSTW and TIMENW. This generic time of day attribute might find a use for Radio broadcast times as well but that can come later. Another proposal for its name is FixedTimeOfDay FIXTIM; so we would have FIXDAT and FIXTIM. However I cannot think of a need for a VARTIM.
Your Questions: I considered the effort required to encode the geographic boundaries earlier. The level of effort is bound to be related to the resolution with which the boundaries are captured. I expect national boundaries are already held somewhere; but I do not know how much effort would be involved in splitting the large states up into their time slices. Probably not a lot. Although the zone time from the longitude slices are not rigidly applied in ships at sea, I do think we need them as well as the national territories, if only because both legal time ashore and the general longitude based time zones do appear in at least two nautical publications and on a chart. It makes sense to be able to do both and I think that your basic idea is right: We do not have to capture the rules but deep sea or on long passages or during long periods at sea, longitude time zone slices generally apply (OBJNAM = Maritime Time Zone "ALPHA" etc), although ships may keep the time of their base port even if they are some way away. I do not think the principle of Daylight Saving Time applies at sea because masters can choose which zone time to use when. In port, the time associated with national territories applies, as amended by their summertime offsets and we need to be able to indicate that.
Just going one step further, we might think a bit about portrayal. Should we try and mimic the two colour effect at sea? I think UKHO uses green and red. (I will try and add a copy). And different colours ashore? With Hatching? or Stiples?
jens 14:03, 1 February 2012 (UTC)Portrayal? I don't think so. I rather thought we need the information for calculation purposes and general country information.
David, I follow your argument that aboard they can choose what ever time they would like to define as their "local time". But when making landfall for landing/berthing purposes at least they have to provide an ETA to someone and that should be provided in LT. Although it is a time ago that was my experience.
Time zone names in OBJNAM is fine for me and the UTC offset in CATTZN too.
I don't understand Raphael's comment
A single attribute for TimeOfDay (TIMDAY? DAYTIM?) should suffice. Whether it is a sub-attribute of SMTSTA or SMTEND indicates whether it is the start or end of summer time.
Does it mean than TIMDAY has to be switched from SMTSTA to SMTEND if the sommer time stops?
raphael 22:35, 1 February 2012 (UTC): FIXTIM is a good name too. VARTIM is not needed for time zones, but what about other contexts? Variable time might be dawn, dusk, sunrise, sunset, daytime, night, daylight hours, high tide, low tide, slack water, "one hour before high water to one hour after", etc.
I agree about the object names and UTC offset.
Boundaries: I think the result is that both of you think TIMZON boundaries should be at least as detailed as the map David linked to? OK
Portrayal: What is the two-colour effect? Searching Google for "time zone map" and clicking the link for "Images for time zone map" produces many maps with different colour schemes. I don't think we can fix it, a scheme that looks good in isolation may not look good combined with other information.
Jens: No, just that SMTSTA/TIMDAY gives the time clocks change on the day when summer time starts and SMTEND/TIMDAY when it ends.
DavidAcland 18:35, 2 February 2012 (UTC) Here is the image which actually has multiple colours and I have no difficulty with leaving the subject of portrayal. There used to be a similar chart which only covers the sea areas but I cannot see it in the current catalogue. File:DSC00833.JPG.
DavidAcland 15:53, 3 February 2012 (UTC) OOPs! Sorry that is so large. Can I make it smaller somehow? I will make the changes and see how we go.
jens 10:29, 18 August 2014 (UTC)Check whether periodicDataRange could replace start and end time?
raphael 19:46, 18 August 2014 (UTC): DSTSTA and DSTEND? periodicDateRange cannot replace those, there are too many differences.