Template talk:Start date text

#time bug list

• December 31,1949 8PM HST -> 1949-01-01 06:00

-J JMesserly (talk) 22:37, 1 February 2009 (UTC)

Tech docs

February 2009:

1. Cull non 4 digit years in all numeric date (eg 01-02-1943)- they will throw an error on any time operation
2. Trap Single years as a special case them. It is a year with no months or days If it is a numeric value, and equal to a 4 digit version of itself. (Because a date like 01-02-1943 is interpreted as subtraction and will not be equal to self). Add single years to 3000 and exit- never using #time.

   If dates is a numeric at this point in the logic, the remaining problem is that low Years are ambiguous. 0069-01 or 69-01-01 are the same as 1969-01 and 1969-01-01. Years 70-99 -> have had 1900 added to them. For 0000-69, «added» 2000. So, final special case:

3. Years not coded but interpreted as 1970- 2069 have 1100 added if less than 2000, and 1000 added if 2000 or greater. Test to identify this case: If the absolute value of the number added together is less than 1000, but the #time extracted year is greater than 1900. Notes: 1) Absolute value because 07-04-1972 would be less than 1000. 2) A better test not relying on math on the date would be nicer because we could allow non numeric- (natural language) dates. If anyone comes up with one, change the code regarding this test.
4. all dates past this point in the logic can be handled reliably with #time and simply have 3000 added to the year that is extracted.

Time zones recognized

Here are the time zones recognized. -J JMesserly (talk) 19:55, 17 February 2009 (UTC)

Daylight saving time

The documentation does not explain how daylight saving time is dealt with. In addition to explaining how this is dealt with, it might be worthwhile to caution editors that substantial research might be needed to determine whether daylight saving time was in force for any particular place and time. --Gerry Ashton (talk) 21:03, 17 February 2009 (UTC)

Yeah- I have been mulling it for a while now. I am glad someone else sees it- I feel like I have some company out here in the wilderness now. I had a recent thought on this- see how it sounds: If the user has a date time with time zone from a source, they should copy paste it. If they don't know the timezone, they should specify it by location, not three letter abbreviation. We might give a map indicating the zone areas, and provide them a recognized location that is in the time zone. This avoids the user confusion about whether a day in march is in standard time or DST. Of course, you understand the problem, but for other readers, here is the problem. Say a user specifies Central daylight time rather than standard time for the JFK shooting. They are off by an hour. Notice though that if we ask the user to specify a location in the central time zone the user doesn't have to know what days are CDT and when it is CST.

DST?	wikitext	display	microformat
savings	{{start-date|November 22, 1963 1pm CDT}}	November 22, 1963 1pm CDT (1963-11-22UTC18)	(1963-11-22 T18Z)
standard	{{start-date|November 22, 1963 1pm CST}}	November 22, 1963 1pm CST (1963-11-22UTC19)	(1963-11-22 T19Z)
n/a	{{start-date|November 22, 1963 1pm America/Chicago}}	November 22, 1963 1pm America/Chicago (1963-11-22UTC19)	(1963-11-22 T19Z)
n/a	{{start-date|July 22, 1963 1pm America/Chicago}}	July 22, 1963 1pm America/Chicago (1963-07-22UTC18)	(1963-11-22 T18Z)

These locations are global and we probably have a location for every zone. (full list here). Of course, this means the user has to use the second parameter to hide the location. EG:

{{start-date|November 22, 1963 1pm America/Chicago|November 22, 1963 1pm}}

Alternatively, there are zones, eg: Canada/Mountain Canada/Central.... This seems like an acceptable price for making it as easy as possible for novices. For experienced folks, we could have an experts section explain the whole DST and UCT offset methods, both of which are also recognized by {{start-date}}.

On second thought, it is by no means fool proof. One error is that some locations of course do not use DST at all, and it is possible that a contributor could specify a location that does observe DST. Here I suggest the Pareto principle (80/20) rule applies, but of course it would be a valid response to chuck the whole location thing and dive in to the complexities, refer users to a site that does a lookup to tell them what the three letter acronym is for the time, date and location (do any exist?). -J JMesserly (talk) 23:57, 17 February 2009 (UTC)

The locations that do or do not observe daylight saving time change over the years. The effective dates of daylight savings time also changes over the years. This year, in New York, USA, DST is in effect on March 8, but it would require research to determine if that was so in 1963. For dates before standard time, editors might prefer to give the date and time directly in UT, because it might be easier to use the longitude of the site to compute UT from local time; if the editor does not live near the site in question, he/she might not be familiar with the present-day time zone intricacies of the area. --Gerry Ashton (talk) 00:40, 18 February 2009 (UTC)

Perhaps the general guidance should be in MOSNUM. Editors attempting to achieve the highest quality articles must understand these complex rules for time zones. Don't you agree? -J JMesserly (talk) 03:35, 18 February 2009 (UTC)

For most purposes, it is sufficient to state the time something happened in the civil time of the location of the event. Applications to make use of microcoded events outside the range of a business appointment calendar barely exist (if at all). Relating events to UT isn't usually necessary unless these kind of applications come to pass. So I would expect resistance from editors. Do microformats offer a provision to express a date and/or time in an unspecified local time? --Gerry Ashton (talk) 04:12, 18 February 2009 (UTC)

Well, at least one of us is thinking clearly. Excellent. Let's punt this issue until that hopefully not too distant future when these Google Time-Space / Wayback machines or other historical apps that use world time materialize. According to spec, if a UTC equivalent value is not specified in the ISO date-time then local time is assumed. (I'll check that again- but I am pretty sure that is the case). UTC ISO values are those with the Z suffix or with a time offset eg -7:00 on the JFK event). Since location is specified for microformat events, there is enough contextual information for a human to make sense of it. This change will mean I have to add an additional parameter onto Start-date because the template is too dumb to figure out if the time will resolve to UT or not. It would be nice if I had string functions to determine this, but I don't. But it will not be the end of the world when contributors inevitably forget to set the flag. A maintenance bot could make a pass and resolve the string to an ISO date- just like the other maintenance bots that run around capitalizing [[category:blah]] to [[Category:Blah]]. If timezone info is present, it can create the ISO8601 value with the Z since Bots enjoy the luxuries of real programming languages and can do this sort of thing. In most cases, user will probably not be specifying the time zone, so the default behavior is to omit the Z. (Opposite of what it does now). We document to the user that local time is assumed unless they use parameter timezone=Yes, which then obligates them to specify information in parameter 1 that will resolve to UT. We warn the user about all the horrors of timezones etc. If the user wants total control they use the ISO8601= parameter and we promise the bot and template won't muck with the value, and just emit it as is. How does that sound? -J JMesserly (talk) 06:29, 18 February 2009 (UTC)

(undent) Default no UTC is now in, and docs changed to reflect existence of the timezone (or by abbreviation "tz") parameter. -J JMesserly (talk) 07:03, 18 February 2009 (UTC)

This sounds good, but I have an observation and some questions. The observation is that the bot would have to be quite clever, and would have to pass over some situations as unresolvable. The bot would need tables that show when DST went into effect for every year since it was first adopted, and a list of locations that do and do not observe DST. So if a time zone were given as CST (central standard time) and the template contained no other location information, it would be unresolvable because some areas in that zone observe it and some don't.

How many specifications for microformats exist? If there are more than one, which one is this template intended to follow?

Finally, using the term UTC for any date before 1961 is an error. True, the ISO forgot to provide any way to indicate time zones before 1961 in their spec, but if we are going to violate their spec, we should say so. Something like "This template intentionally violates ISO 8601 by using the suffix Z or time zone information for times that are based on Universal Time rather than Coordinated Universal Time (UTC) for date before UTC was established. This is just a formality, since very few times stated in articles are known precisely enough for the distinction to matter." --Gerry Ashton (talk) 14:58, 18 February 2009 (UTC)

I think the bot should pass on anything it is unsure of. As we get into the details, it may turn out that this set is large. However, even if this is a high percentage, the bot can be of assistance, flagging dates with a hidden maintenance category indicating a possible problem with a microformated date. I can say that I personally have no intention of attempting to out think human contributors, nor to substitute human editing with an algorithm that can determine with great certainty the timezone given a natural language description. I don't want to dissuade any engineers who may later stumble over this conversation- Of course it might be possible to create such an assistant, but as you intimate, the task would be non trivial. No- I was thinking along the lines of fixing clear errors in what was intended, like specifying UTC or -7:00 when the tz flag was not dropped. When I go to work on that cleanup bot, I will notify you and I'd appreciate it if you would help me identify any rules that could err.

Dates are specified in the hCalendar spec, which was designed to closely follow the iCalendar (RFC2445) standard [1] created with the goal of creating "interoperable calendaring and scheduling services for the Internet". Here is the list of microformats specifications[2]. Below you will see a list of draft specs. The microformats.org community is not like a typical ISO standards process, but in many respects that is good due to the provisional nature these specs out to have as more is learned about this sort of approach in data sharing. The dominant two microformats are hCard and hCalendar, motivated initially to model contacts and appointments for the schedulers in email programs. Some are sophisticated in their microformats awareness like apple's iCal. A book on microformats is out[3], though it is kind of fluffy with a lot of html cookbook examples to get sites to employ microformats.

Tactically, given that the microformats community appears to follow compelling examples of usage, I suggest we might embark with an extension of the principle of assuming local context. We contine along in the manner of the rule for timezones which says that when timezone is unspecified and the local context is a place, then the local timezone is assumed. Proposal: We define Z usage as UT (universal time) with the language of your explanation above for divergence from ISO8601's UTC. When the UT indicator is not used, then if the calendar for a time period and place is something other than gregorian, then that local calendar should be assumed. We put that into MOSNUM, and make it explicit on the microformats page, and announce to the microformats.org community that this is our (non binding) guidance to editors. -J JMesserly (talk) 16:10, 18 February 2009 (UTC)

Books/PDF

I have been experimenting with the relatively new Wikipedia book feature, including the Download as PDF function. The dates produced by this template are blank in this format. Could someone take a look at Help:Books/for experts and determine what the problem is? Thanks. Hal Jespersen (talk) 15:19, 12 May 2010 (UTC)

Move discussion in progress

There is a move discussion in progress on Template talk:Birth-date which affects this page. Please participate on that page and not in this talk page section. Thank you. —RMCD bot 17:34, 15 September 2023 (UTC)