An Introduction to the Denarius Verus time and calendar system Clocks around the world in dow. Numbers given are longitude, time zone, and time with London at noon. Honolulu Mexico City Rio de Janeiro Casablanca Berlin Antananarivo Dhaka Tokyo Los Angeles New York Reykjavik London Kyiv Delhi Beijing Auckland -157.9 -118.2 -99.15 -74.0 -43.2 -21.9 -7.6 0.1 13.4 30.5 47.5 77.2 90.4 116.4 139.8 174.75 -44 -33 -28 -21 -12 -6 -2 0 +4 +8 +13 +21 +25 +32 +39 +49 06.0 17.0 22.0 29.0 38.0 44.0 48.0 50.0 54.0 58.0 63.0 71.0 75.0 82.0 89.0 99.0 The calendar isn't very interesting to look at. It's the same for every year. Half-weeks are shown by periods. The first day of each traditional month for a non-leap year is shown by a colon after the day number - for a leap year they're one day later starting with March. Where both a new half-week and an old month coincide, there appears a semicolon. The new days are Marsday and Joveday. 1 July is on marsday most years, but joveday in leap years. Winter 0 Winter 1 SuMoTuWeThFrSaMaJo SuMoTuWeThFrSaMaJo A 0:1 2 3.4 5 6 A 0 1 2 3.4 5 6 B 0 1 2 3.4 5 6 B 0 1 2 3.4 5 6 C 0 1 2 3.4 5 6 C 0 1 2 3.4 5 6 D 0 1 2 3.4 5 6 D 0 1:2 3.4 5 6 F 0 1 2.3:4 5.6 7 8 E 0 1 2 3.4 5 6 7 Spring 2 Spring 3 SuMoTuWeThFrSaMaJo SuMoTuWeThFrSaMaJo A 0 1 2 3.4 5 6 A 0 1 2 3.4 5 6 B 0 1 2 3.4 5 6 B 0 1 2 3;4 5 6 C 0 1 2 3;4 5 6 C 0 1 2 3.4 5 6 D 0 1 2 3.4 5 6 D 0 1 2 3.4 5 6 F 0 1 2.3 4 5.6 7 8 E 0 1 2 3.4 5 6 7 Summer 4 Summer 5 SuMoTuWeThFrSaMaJo SuMoTuWeThFrSaMaJo A 0 1 2 3.4 5:6 A 0 1 2 3.4 5 6 B 0 1 2 3.4 5 6 B 0 1 2 3.4 5 6 C 0 1 2 3.4 5 6 C 0 1 2 3.4 5 6 D 0 1 2 3.4 5 6 D 0 1 2 3.4 5 6 F 0 1 2.3 4 5.6 7:8 E 0 1:2 3.4 5 6 7 Summer 6 Autumn 7 SuMoTuWeThFrSaMaJo SuMoTuWeThFrSaMaJo A 0 1 2 3.4 5 6 A 0 1 2 3.4 5 6 B 0 1 2 3.4 5 6 B 0 1 2 3.4 5 6 C 0 1 2 3.4 5 6 C 0 1 2 3;4 5 6 D 0 1 2 3;4 5 6 D 0 1 2 3.4 5 6 F 0 1 2.3 4 5.6 7 8 E 0 1 2 3.4 5 6 7 Autumn 8 Winter 9 SuMoTuWeThFrSaMaJo SuMoTuWeThFrSaMaJo A 0 1 2 3.4 5 6 A 0 1 2 3.4 5:6 B 0 1 2 3.4 5:6 B 0 1 2 3.4 5 6 C 0 1 2 3.4 5 6 C 0 1 2 3.4 5 6 D 0 1 2 3.4 5 6 D 0 1 2 3.4 5 6 F 0 1 2.3 4 5.6 7 8 E 0 1 2 3.4 5 6 7 (leap) F 0 1 2.3 4 5.6 7 8 Denarius Verus is the calendar extension of the True Decimal time unit, the hy (Huygens), defined as one millionth of a day. First, a note about the name. I don't speak latin, but that's how these things are done. I went to a grammar and dictionary to translate "true decimal", and in the usual way of translations, the closest phrase I could find apparently meant "truly by tens". Clearing my mind and looking at the definitions again to see what I would think "denarius verus" meant if I didn't previously know, I thought that the most recognizable specific meaning was "really paid the land tax". Looking at the broader array of meanings possibly available, what I would prefer is "accurate to the penny". Although in latin (more or less), it should be considered a tag like CE and not part of a larger latin grammatical construction like AD is sometimes used. A note to English speakers: both letters "e" should be pronounced the same, and different from the "a". For civil time, I suggest dividing the day into 100 decimal-hours or dows of 14.4 minutes, and those into 10 decimal-minutes of 1.44 minutes, which in turn is the khy or "kie". Times should be expressed in writing as a decimal number of dows: hh.msss more or less. For human purposes dows will usually be precise enough, and khy are easy to use for more precision. Examples: the meeting will be from about 40-50 i.e. 9:30 (literally 9:36) to noon; come by before 72 (17:17) and be there on time - I'll be gone by 72.3 (17:21). Dial clocks would have 10 major marks around the circimference, labelled 0, 10, 20, ... 90. The 100 smaller marks would be too indistinct for most purposes, so you wind up with a design which may have 2, 3, or 4 hands depending on the precision. An hour-only clock has two hands, the day hand which is a 24-hour hand moving at 1*2pi microwu (hour hand 2*2pi muwu), and the 10-dow hand which moves at 10*2pi muwu. In effect the 10-dow hand indicates the digit of the dow on the main marks, and the khy on the smaller. You can then add a dow hand at 100*2pi muwu to indicate the khy more clearly, and so on. Here is the new calendar: years follow the Gregorian system (for the next thousand years or so - see below regarding the eka-Gregorian leap year), and indeed the use of the AD year is allowable. On the other hand, it does seem a convenient time to start a new epoch, and so I recommend DV (Denarius Verus) in which AD2001 is declared year 1. In DV, 0 is 2000AD (the DV epoch), -1 is 1999AD etc. The same divisibility rules can be used for leap years as in AD. The year is divided into ten non-months or nonths, which can be either 36 or 37 days long. The first nonth of the year is numbered 0 and lasts 37 days, as do all even-numbered nonths. The second is numbered 1 and lasts 36 days, and the long and short nonths alternate, except that nonth 9 is long in leap years, i.e. leap day is the last day of the year. Each nonth has 5 weeks exactly, and so there are always exactly 50 weeks in the year, which always starts on Sunday and ends on... I'll get to that. The weeks obviously must vary in length, but on the other hand they occur much more regularly in the calendar. In fact the way of writing the date is to give a name to every week in the year, and then finish the date with the weekday instead of a month day. The five weeks are given letters A-F. The letters A-D always denote 7-day weeks, and those are the first 4 weeks of every month. The fifth week of a short month is called E and has 8 days, and the 5th week of a long month is called F and has 9 days. Like everything else the days are numbered from zero, so the first day of the year is always Sunday 0A0, and the last day of the year is 9E7 is most years but 9F8 in leap years. Day 0 is Sunday, day 1 is Monday, and I propose Marsday (Mrs) for day 7 and Joveday (Jov) for day 8. In terms of the half-week model, the 7 day week is a 4-day half-week followed by a 3-day half-week, the 8-day week is two 4-day half-weeks, and the 9-day week is 3 3-day half-weeks. This is a good principle for figuring out how to schedule things that are suposed to happen once a week: the 8-day week is just a long week, but the 9-day week is really 3/2 of a week. This system ends up with 105 or 106 half-weeks per year. So for a 4-day work week you have 209 work days per year without holidays or vacations, and with the new calendar based on the 2 days per half-week principle you get 210-212 per year. For a 5-day work week the new rule would be 5 days every 7-day week and 6 days for either E or F weeks which gives 260 or 261 per year, compared to 261 for the old calendar. As for French names for the new days, mardi is already taken, so I propose saturdi and jovedi. Here is a summary of how to schedule things n times per old week: Old n/yr New n/yr 1x Wed 52 Wed A-E, Tue Fri F 55 2x Mon Thr 104 Mon Thr A-E, Mon Thr Sat F 105 3x Mon Wed Fri 156 Mon Wed Fri A-E, Mon Wed Fri Mrs F 155 4x Mon-Thr 209 Mon-Thr A-E, Mon-Wed Fri-Mrs F 210 5x Mon-Fri 261 Mon-Fri A-D, Mon-Sat E-F 260 6x Mon-Sat 313 Mon-Sat A-D, Mon-Mrs E-F 310 The nonths can be given names based on the season. Where I live, the names would be Winter-0, Winter-1, Spring-2, Spring-3, Summer-4, Summer-5, Summer-6, Autumn-7, Autumn-8, Winter-9, with abbreviations like Wn1, Sp2, Sm4, At7. The names and abbreviations of the days and nonths are arbitrary, and software should ignore their value and focus on the central digit-letter-digit date sequence. Some examples will make it more familiar. Right now it's 23 Wn1 E 0 Sun 92.6750, or what's normally called Tue Mar 7 2023 10:14:31pm. The date can be printed in a more concise format: 23:1E0:92.6750. Both formats are naturally of fixed length, except for the year. The names assigned to the nonths may vary by location, but should always use a 2-letter abbreviation so that software can skip over the two letters and just use the digit. It's possible to convert dates between the two systems in your head, but it requires patience and some skill at multi-step mental computation. The basic idea is to calculate the Julian day number on both sides. As an example, I'll use the date of the great game 5 of the 1979 world series, 14 Oct 1979, which is a pretty difficult one. Up to Oct, there are 5 31-day months, 3 30-day months, and a 28-day month in this non-leap year, so that 1 Oct is day 273 starting from 0, which makes the 14th day 286. Now perform integer division by 73: 286 = 73*3 + 67. The remainder 67 is greater than 37, so we're in nonth number 7, day number 30. Perform integer division by 7: 30 = 7*4 + 2. Since 7 is odd this is a short nonth, so week 4 is E, and the day is 2 or Tuesday. That makes -21 At7 E 2 Tue (it was Sunday in the current calendar). As for time zones, I propose to establish new dow-based zones by a two-step procedure. In this system time zones should be defined as far as possible using lines of longitude. Each time zone will take its time offset from a line of longitude which passes through it. The system is still based on GMT as the zero-offset meridian. The first stage of the definition is to define 100 natural dow-zones each of which has a central longitude of n*2pi/100 with n=0,1,...,99, and extends from [n-.5, n+.5)*2pi/100. The international date line works the same way as at present, and should presumably stay in the same place. The natural zones range in offset from GMT-50dow to GMT+50dow, with the date line zone split in 2 giving 101 total. The second stage of the definition of new time zones is to define political zones which may have boundaries which include national borders in addition to lines of longitude. If possible it is best to use the time of one of the natural zones whose central line of longitude passes through the territory, but in principle any line of longitude which intersects is allowable (akin to present-day half-hour time zones). At present you can take your dow zone from your longitude (example: I'm at 73.6W, so 73.6/3.6=20.44, so I'm in GMT-20dow). Alternately, you can use your hour-zone to estimate a longitude (ex: I'm currently in GMT-5, which gives 5*15=75W, and 75/3.6=20.83 so that estimate gives GMT-21dow). Note that dow time does not have daylight savings time. If you estimate your dow-zone from a time zone with DST, you will get a sort of dow-DST that way (ex: in the summer I'm GMT-4, and 4*25/6 =16.67, or GMT-17dow). As explained below, the default clock representation described so far is called ITH, and so the time zones are called e.g. ITH+0, ITH-21 etc. DV will have leap seconds, or rather leap intervals in hy. There has been some controversy over this issue recently, and I believe the answer lies in a light reworking of software timekeeping, which will be standardized for DV. In short, in DV leap intervals will be a part of the time zone offset, and the DV equivalent of Unix time_t will not have leap intervals. Let me back up a bit and describe roughly how the current time is determined on a modern Unix OS. There are two hardware clocks and three stages to the software process. The first clock is simply a hardware counter of machine cycles since the last reset, called the TSC (time stamp counter) on x86. The second is a battery-powered clock which is supposed to keep the date and time of day in GMT. At boot up, the battery clock is consulted to establish a calibration of the TSC to GMT. So the first stage of the ordinary determination of time is to read out the current TSC, and the second stage is to produce a product called time_t, traditionally the integer number of SI seconds since the 1970 epoch. Crucially, leap seconds are added to time_t. NTP adjusts the calibration constants between the TSC and time_t. The third stage is to convert time_t to the date and time of day in what I call the broken-out representation with separate integers or strings for month, hour, etc., which is done by the functions gmtime and localtime, the latter including the timezone offset. Occasionally the time and date determined by gmtime (hopefully with the help of NTP) may be written to the battery clock to keep it up to date - not only does it not know about leap seconds, but it tends to keep terrible time. If TAI is available at all it is calculated by the hair-raising procedure of subtracting the leap seconds back out of time_t and then returning a broken-out representation. Of course DV will have to contend with the same hardware, but a crucial difference can be made in the procedure. It's a good idea to think about what questions are being asked in these different stages of the process. I think the following sequence of questions points to a better procedure: 1. how many tick since reset? 2. where is now in the universal timeline of human history? 3. what day is it and what is the time of day? I wish to standardize the following process for answering these questions, and so I will give the answers names and in some cases data representations. First, LTB (local time base) is a nondecreasing integer time scale with arbitrary epoch and tick rate, not exposed to users as a part of DV. In many systems this will be determined by the format returned by a hardware system like the x86 TSC, but on some systems it will be kept in software by the timer interrupt. The DV second stage is similar to Unix but without any leap seconds or intervals ever being added. This is called MTH (mesure de temps en hy or measure time in hy), and should be represented by a pair of 64-bit integers called dv_mth_t. The two members hy and ahy give the time since the MTH epoch. This is defined in terms of 2023 GMT but transposed back to 1 Jan 2000 which gives an epoch of 00:00:05 GMT on that day, there having been 5 leap seconds inserted in the interim. So the hy member of dv_mth_t counts the signed number of hy elapsed since 00:00:05 GMT 1 Jan 2000, as determined by TAI or JD which it should be considered equivalent to by affine transformation. This gives it a range of +/-25 billion years. The unsigned member ahy counts the atto-hy since the time indicated by hy. Alternately, a type dv_mth2_t could have members hy and Fhy, with Fhy (fractional hy) giving the time since hy in units of 2^-64 hy. The choice between these representations should be left up to the implementer. Floating point should not be used. Finally, MTH is converted to ITH (indice de temps en hy or index time in hy) which gives the date and time of day, by a function which should be called something like dv_ithtime. This is done by adding the accumulated quantity of leap intervals since 2023, and then adding a time zone offset. The point is that both time zones and leap seconds exist to align astronomical noon with clock noon as well as physics and politics allow. MTH is like TAI, or even better JD, intended to measure the time difference between events as accurately as possible. The name index time indicates a slight difference in philosophy, namely that the purpose is to indicate the time of day and not to accurately measure intervals, desirable as that may generally be. Therefore the rule for leap intervals is that they should be inserted either 10hy or 20hy at a time (.86s and 1.7s) and always at 99.9999dow in the day, and that the time display should simply freeze during that interval. No time greater than 99.99990 is ever to be displayed in ITH. Also in keeping with this philosophy, no historical leap intervals will ever be defined, as they serve no purpose in indicating the present time. As I say above, MTH should in all cases be used for the accurate measurement of intervals. I describe above how to compute ITH from GMT away from leap seconds by selecting a dow-zone and computing time from GMT midnight, with an adjustment for the leap-interval difference between GMT and ITH. Eventually a system for coordinating the addition of 10 and 20hy leap intervals will be put into place, but until then you can simply use the 11.574hy leap interval provided by GMT, freezing time at 99.9999 for that duration (plus the 1hy it normally lasts). If a leap interval must be removed instead, the time should skip forward by the correct amount just before midnight. I will repeat that ITH is only for use on human-readable displays and for events coordinated by such means. In particular software should always use MTH internally and convert for display. The broken-out variables returned by dv_ithtime include the integral values ihy (integer part of the time after the decimal point), idw (integer part of the time before the decimal point), wkd (day of week), wk (week of nonth), non (nonth of year), year (DV year), yday (Julian day of year). One might well question why leap intervals should be contemplated at all when they have apparently been scheduled for retirement in GMT. I believe the context of the two situations is rather different, and I'm certain the issue will be raised again in the future even if the current compromise seems obviously preferable in the present situation. I think the origin of the problem - leap seconds were recently declared a hazard to navigation, for example - lies in inappropriate use of what I call "index time" based on a combination of confusion, ignorance, and an unwillingness to switch to a little-known time base which is nearly half a minute offset from GMT. In proposing an entirely new time system I believe I can overcome the ignorance and inertia, as everyone will be forced to take a look at the new thing eventually if it catches on. So long as the documentation for the new system is clear on this point we shouldn't have anyone attempting navigation with index time. I also believe that eventually the original logic for leap intervals will reassert itself, so it makes sense to use this opportunity to revisit the issue. I propose that for the first decade after ITH has been officially established, there should be a moratorium on leap intervals so that during the transition period switching to the correct time base will be painless. On the other hand this could obscure the difference between them, so another idea is for the first decade to insert and remove 10hy leap intervals in alternate years on schedule, displaying the difference and shaking out software implementations, while giving regular intervals for zero-offset switching. In all cases it must be made clear that software implementations must be based on MTH primarily, and must offer MTH if ITH is available. While proposing an overhaul of the Gregorian calendar, I can't omit to consider one further aspect, which I believe has been somewhat overlooked, involving the evolution over time of the leap year rule. The long term rotation rate of the earth as expressed in the length of the tropical year in days is estimated at around 365.2422. If we imagine the current sequence of rules applied in a somewhat ahistorical manner, we get the following sequence of lengths: 365; 365.25; 365.24; 365.2425. And in making these adjustments we, in the same order, added a leap day, removed a leap day, added a leap day. What I would like to point out is that this procedure only works if each step is an overcorrection. It is vital that the sign of the correction change each time, otherwise you would have to either add or remove a leap day out of sequence somewhere. This is relevant because a change has long been proposed to add a next rule removing a leap day every 4000 years, resulting in a length of 365.24225, which is a very good approximation indeed. And I admit it's unlikely that a calendar would survive long enough to need the following correction in the sequence. Nonetheless, that correction would be difficult to make because it would apparently involve removing another leap day out of sequence. So I propose a new rule removing a leap day every 3200 years instead, giving a length of 365.2421875 and likely guaranteeing the next correction will be in the proper direction. DV therefore uses this new leap-year rule, however the year is to be converted back to AD to make the calculation! This is mainly to cover for the fact that 0DV was in fact a leap year, but also to ensure that the first triggering of the 3200-year rule should be early in the above sense; therefore 1200DV shall be the first 400-divisible non-leap-year. 0AD conveniently doesn't exist. I call this new leap year rule "eka-Gregorian" in anticipation of further refinements. The 4000-year rule could then be recreated as "dvi-Gregorian" with a 16000-year rule (3200*5), this time with the correction going in the right direction again. Another multiple of 3200 may be prefereble for dvi, of course, based on future measurements. I believe I have adequately addressed the issues of time zones. leap years, and leap seconds or intervals; there will be no provision whatever for daylight savings, neither for a permanent offset of a time zone from astronomical noon. Here is the part of the README file from the software download to do with DV: This is a set of tools for using the True Decimal system of units of measurement, and for using the Denarius Verus calendar and clock system in software. The file newcal contains a text DV calendar for every year. First, the bad news: there is currently no proper implementation of MTH. This requires a kernel module, and although I am looking into this, I have not started yet. I know my own specification requires MTH first of all, but that requires more planning than this exploratory effort. What does exist is a preliminary workshop for ITH and the DV calendar in Perl5. Leap intervals and GMT leap seconds are not currently supported, and the API should be considered in flux. In particular this implementation stays closer to Perl-ish style since it uses Unix time_t underneath instead of MTH, while the new API for DV is intended to swim off in another direction. There are a number of software tools for exploring DV. dec-day will print a conversion table for times throughout a day, at a given interval in the "old" or "new" units. By default it prints a table for every hour, which is equivalent to running './dec-day -o 1'. If you want a table for every dow in the day, run './dec-day -n 1' etc. The utility dec-date simply prints the current date and time in "short" format. The utility dec-clock is a terminal-based clock. It's meant to be run in a small terminal to continuously display the time, although if you use the -w option it will run in "stopwatch" mode printing the time whenever you press enter. Otherwise it defaults to clearing the screen evey 10hy and printing the time and date in DV "pretty" format. If you want an update interval other than 10hy just pass that integer as an argument to the program e.g. './dec-clock 1'. By default it will synchronize to a ..0 display at the end of the time by delaying briefly at startup. Use the -S option to supress this behavior. Finally the -C option will supress the screen clearing. The DV time zone needs to be properly set before the time will be correct. Edit the file and follow the instructions at the top to find out how to do this. By default it is set for Montreal (DVZ ITH-20) via the longitude input. The utility dec-conv is the most sophisticated and useful. It can take inputs concerning dates, times, and time zones in a variety of "old" and "new" formats and make conversions or print tables to specification. It is an interactive program with a prompt for input. If you just press enter you get a "current time" display in both formats as well as a reminder of the time difference between the DVZ and the old-style (I want to say AD) time zone. Here are some time formats it recognizes: 10am 10:00 10:00:00 10h 10h00 99.9999 99,9999 dates: y/m/d d/m/y y-m-d d-m-y (other orders excluded) complete timestamps: Thu Mar 9 21:41:51 2023 23:1E2:12.3456 23 Wn1 E 2 Tue 12.3456 Whenever date and time inputs appear it does its best to recognize them piecemeal in any order, but not all possibilities are uniquely recognizable. If the input consists of only a date and/or time, it will display the resulting date and time in both formats. It also produces a summary of what it saw in the input. There are also special commands you can use. Foremost, there are comands to inquire and set the TZ and DVZ time zones. Just typing either of those will get the current settings printed. Add an equal sign and a number to set them directly e.g. 'DVZ = -25'. To set DVZ by longitude, use 'long = -90' where minus means west. The command 'oldweeks' prints a table of the date of every Sunday in the old calendar in both systems, and 'weeks' does the same for the new weeks. 'months', 'nonths', 'hours', and 'dows' are pretty much the same thing. Finally, there is the central software library in perl, dv_lttl.pl whose internal documentation is reproduced here. Denarius Verus localtime / timelocal library This library implements the Denarius Verus calendar in Perl via the familiar localtime and timelocal functions, as well as some pretty-printing and also functions to handle the new time zone system and leap year rule. These functions, being based on Unix time_t, are not really suitable for periods far in the past. Also, Perl translates time_t into a floating point number which can ruin time precision over longer periods. For example times of day calculated before about 50 years ago are inaccurate in some situations. Special attention should be paid to the numerical value of the year. Denarius Verus has a new epoch for the year, so that the year 0DV corresponds to 2000AD. The year is always passed in this format in this module. Neither AD nor the Unix localtime year are correct. The current release entirely lacks support for MTH, leap intervals or GMT leap seconds. dv_isleap Returns bool. Takes year (int). Tells you whether a year DV is a leap year. Note that 1200DV is not a leap year, as the new calendar has a new 3200-year leap-supressing rule (like the Gregorian 100-year rule), which is in effect applied to the AD year value. dv_hourzone Returns zone (int). Returns the offset of localtime from GMT in hours, by calling localtime and gmtime on the (same) current time and subtracting. $dv_long In degrees, -180 to +180, + means E and - means W. Used to set the (dow) time zone. This is the recommended way of choosing your natural dow zone. 50.0000 should be within about 2 dows of literal local solar zenith at worst (assuming the sun has risen). $dv_DVZ In dows, -50 to +50. Used to set the dow zone directly. dv_dowzone Returns zone (int). Returns the offset of dv_localtime from GMT in dows. If $dv_DVZ is set it uses that value, clamped to the valid range. If it's not set, it turns to $dv_long to compute the natural dow zone from longitude. Finally if none of those are available it computes the closest integral dow zone to your current hour zone. In any case this will generally not be equal to your hour zone, neither to an integral (hour OR dow) offset from it. dv_isshortnon Returns bool. Takes year (int), non (int). Is this non short (36 days, final E week ends on Marsday) or long (37 days, final F week ends on Joveday)? In case the non is 9, you need to pass the year (DV) also to check for leap year. dv_non Returns non (str). Takes non (int). Converts non to the default 3-letter abbreviation. dv_wk Returns week (str). Takes year (int), non (int), week (int). Converts week number to single-letter format. Needs to call dv_isshortnon for week 4, so pass those arguments as well. dv_day Returns day (str). Takes day (int). Converts day to the default 3-letter abbreviation. dv_localtime Returns timestamp (str) in scalar context or ($ihy, $idw, $wkd, $wk, $non, $year, $yday, $dow) in list context (all int except dow is FP). Takes t (time_t). Performs the same basic function as traditional POSIX localtime, but returning the new set of broken-out time variables or a new short string format timestamp. The time zone is calculated by calling dv_dowzone. The string format "short stamp" is the shortest (readable) expression in text of the DV time and date, and uses the colon as separator because the syntax can't be confused with traditional times (e.g. there's always a letter in the middle). The new format looks like the following, from left to right: year non wk wkd idw ihy 23:2A2:83.6380 The broken-out numbers are those above (week in number not letter form - E and F are both 4). Year is in DV, non is 0-9, and wkd (weekday) is 0-8. The time is given twice, as floating point in dow, and as a pair of integers ihy and idw typically to be printed as sprintf("%02d.%04d", $idw, $ihy). yday is exactly the same as localtime. dv_timelocal Returns t (time_t). Takes dow (float) , wkd (int), wk (int), non (int), year (int). A copy of timelocal from Time::Local. See dv_localtime for a description of the values and their ranges. Note that different weeks have different lengths, so watch out for valid wkd values. dv_gmtime Returns timestamp (str) in scalar context or ($ihy, $idw, $wkd, $wk, $non, $year, $yday, $dow) in list context (all int except dow is FP). Takes t (time_t). The equivalent of gmtime. The +0 zone is also at the same meridian, so it's really the same thing. dv_timegm Returns t (time_t). Takes dow (float) , wkd (int), wk (int), non (int), year (int). A copy of timegm from Time::Local. See dv_localtime for a description of the values and their ranges. Note that different weeks have different lengths, so watch out for valid wkd values. dv_timelocaljd Returns t (time_t). Takes dow (float) , yday (int), year (int). This is like dv_timelocal, but if you have the Julian day instead of the date. dv_timelocalss Returns t (time_t). Takes shortstamp (str) This is like dv_timelocal, but parses the shortstamp format, including optional time zone. dv_timelocalps Returns t (time_t). Takes prettystamp (str) This is like dv_timelocal, but parses the prettystamp format, including optional time zone. dv_timegmss Returns t (time_t). Takes shortstamp (str) This is like dv_timegm, but parses the shortstamp format. dv_timegmps Returns t (time_t). Takes prettystamp (str) This is like dv_timegm, but parses the prettystamp format. dv_timelocaltz Returns t (time_t). Takes tz (int), dow (float) , wkd (int), wk (int), non (int), year (int). Does the same thing as dv_timelocal but for the specified timezone instead of the current one. dv_timelocaljdtz Returns t (time_t). Takes tz (int), dow (float) , yday (int), year (int). Does the same thing as dv_timelocaljd but for the specified timezone instead of the current one. dv_timegmjd Returns t (time_t). Takes dow (float) , yday (int), year (int). Like dv_timegm but takes the Julian day instead of the date. dv_prettystamp Returns timestamp (str). Takes t (time_t). Gives a longer format timestamp than dv_localtime in scalar context, including the month abbreviation and the day abbreviation, and using spaces instead of colons. Calls dv_localtime. 23 Sp2 A 2 Tue 83.6380 dv_prettystamptz Returns timestamp (str). Takes t (time_t). Calls dv_prettystamp and appends the time zone to the date. 23 Sp2 A 2 Tue 83.6380-20 dv_prettystampgmt Returns timestamp (str). Takes t (time_t). Gives a longer format timestamp than dv_gmtime in scalar context, including the month abbreviation and the day abbreviation, and using spaces instead of colons. Calls dv_gmtime. dv_prettystampgmttz Returns timestamp (str). Takes t (time_t). Calls dv_prettystampgmt and appends the time zone (i.e. a fixed '+0') to the date. dv_shortstamp Returns timestamp (str). Takes t (time_t). Calls scalar(dv_localtime($t)). dv_shortstamptz Returns timestamp (str). Takes t (time_t). Calls scalar(dv_localtime($t)) and then appends the time zone. dv_shortstampgmt Returns timestamp (str). Takes t (time_t). Calls scalar(dv_gmtime($t)). dv_shortstampgmttz Returns timestamp (str). Takes t (time_t). Calls scalar(dv_gmtime($t)) and appends '+0'.