• Alister (unregistered)

Only 17 more months to go before 2020 is finally over.

Yep, that 's actually seeming pretty true this year.

• Erwin (unregistered)

So with a date like 25-03-2020, the frist number could point to what 12-day month it is?

• Ruud van der Graaff (unregistered)

I read this and my first thought was WH 40k Why: https://warhammer40k.fandom.com/wiki/Imperial_Dating_System Example: So the year fraction for 18 July 2005 would be 549 and the year would be written 549.005.M3.

IIRC nobody has implemented this system ( sofar)...........

• Red Five (unregistered)

The dating starts off sounding like stardates from the Star Trek reboot. But then the calculations go wrong...

• Brian (unregistered)

Wow, a 40K reference before a Star Trek reference. Young 'uns these days...

• Bart (unregistered)

Why not simply extend the YYYYMMDD scheme to a float: YYYY.MMDD. So, 2020.1231 would be the past day of 2020. Can be easily sorted, can be converted back with relative ease as well.

• (nodebb) in reply to Bart

If this is done for things like statistical modeling, then the purpose would be to have a number line that represents the linear passage of time (at least within the span of each year), not necessarily the calendar date. Any year/month/day scheme can't do that because months don't have equal lengths.

• SheriffFatman (unregistered) in reply to Bart

Why not simply extend the YYYYMMDD scheme to a float: YYYY.MMDD. So, 2020.1231 would be the past day of 2020.

Okay:

some_date = 2020.1231 month_and_day = some_date - 2020 print(month_and_day) 0.12310000000002219

Err ...

• SheriffFatman (unregistered)

So I borked the formatting. That should have been more like this:

\$ some_date = 2020.1231 \$ month_and_day = some_date - 2020 \$ print(month_and_day) 0.12310000000002219

• SheriffFatman (unregistered)

Aaah I give up

• Naomi (unregistered)

Use four leading spaces for a code block (which will also escape the angle brace).

``````> some_date = 2020.1231
> month_and_day = some_date - 2020
> print(month_and_day)
0.12310000000002219
``````

TRWTF is TDWTF not having a preview button. Remy!

• Anonymous Coward (unregistered)

I could swear that Paradox internally stored datetimes as floats and interfacing with a Delphi veteran who could convert them in his sleep.

• Ruud van der Graaff (unregistered) in reply to Brian

Dear sir, I am 20 but with 36 years of extra experience ;). Old enough to witness COBOL, Fortran and motorola 6809 code..........

• (nodebb)

So what's so wrong with the common way of doing this: number of days (with decimals) since some epoch start date? The best part is that it's very easily implemented on top of your favorite date library. Of course, this is TDWTF, so if they did that, they'd never have an article here.

Considering a year to be a time unit is actually quite insane given that a year has no standard length. There are the two common lengths and then we have the leap-second issue. If they intend to use Julian year instead of calendar year -- that's another can of worms that should really stay closed.

• (nodebb)

Ever since the COVID lockdown I haven't had any dates at all. Maybe our calendar system shouldn't either.

• Date To Date (unregistered)

So what's so wrong with the common way of doing this: number of days (with decimals) since some epoch start date?

Nobody can read it. That's the only problem (apart from overflow if you use the wrong data type), but it can be important - even if they're supposed to be values for a computer, it's nice to be able to look at database tables or logs or debug into applications and immediately see the wrongness.

I typically use epoch seconds because it's a bit of a standard and it saves you having to write much date handling code, although I bet I have some leap year or leap second related minor WTFs left behind me. (It does save you from the most obvious summer time related problems though.) But I understand the motivation for something like in the article.

• Shawn (unregistered)

You didn't point out that this approach of truncating a 32 bit value to 16 bits by casting the pointer before dereferencing is making an assumption about processor endianess, relying on undefined behavior that will give wrong results on big endian CPUs.

• Just Me (unregistered) in reply to Jaime

It's not just years which have a variable length. Remember that the last minute of June and July could have leap seconds added or subtracted. In fact, it's theoretical that multiple seconds could be added or subtracted. Also note that a human decides when to invoke leap seconds, so there's no computer function for calculating them.

• Prime Mover (unregistered)

Oh dear.

I can't unSee that. I think I'm about to unDrink my coffee.

• Prime Mover (unregistered) in reply to Ruud van der Graaff

yeah okay, big boy, but have you done CORAL-66?

• (nodebb) in reply to Ruud van der Graaff

I read this and my first thought was WH 40k

Damn, I got ninja’d …

IIRC nobody has implemented this system ( sofar)...........

For use in the real world or as a thing aimed at 40K players? Because I have done the latter.

• (nodebb) in reply to Shawn

they don't cast a pointer before dereferencing anywhere. they dereference unYear then cast that value to a float (which promptly gets turned into a double when it deals with 365.0, but that's a whole other can of worms)

| Aaah I give up

TRWTF is this bastard markdown with no preview and no documentation.

• Twither (unregistered) in reply to Shawn

Who's casting pointers? I don't see any pointer casts.

• King (unregistered) in reply to Prime Mover

I have

• I dunno LOL ¯\(°_o)/¯ (unregistered) in reply to sizer99

But it's Markdown, the documentation is everywhere! Too bad if it's not exactly the same as the version used here, though...

• Doug (unregistered) in reply to Anonymous Coward

I could swear that Paradox internally stored datetimes as floats

IIRC it did what Delphi does, and what Jaime mentioned just two comments later: stored the floating-point number of days since an epoch date.

SQL Server does a similar thing under the hood, but Delphi's epoch date is two days different from SQL Server's epoch date. Subtle casting bugs ahoy!

• Z (unregistered)

Using floats for time is DANGEROUS. The problem is when you go to add a day, but one day is a rounding-error in the float representation. People always forget that a big number + a small number can == the same big number again. This caused the Patriot missile system to let people die in Iraq. They were counting time since boot in mS, and after many days of uptime would stop tracking incoming missiles properly since they couldn't calculate time deltas properly. Now - then == 0, perpetually till the next reboot. The excuse was the original use case was to only be up and running like three days or so before shutting down to be moved again.

• eyalnesher (unregistered)

The existence of the code itself isn't TRWTF, the reversed division can be a genuine mistake, and the general approach is naive, but not that far off. TRWTF is whoever wrote this code probably didn't test this at all before publishing it. I don't know where it was found, but I wonder how much time it was there before someone noticed it.

• Katie E (unregistered) in reply to Bart

It wasn't our date to process. The format comes from the world magnetic model coefficients file which is used to calculate magnetic variation. The format is given as "WMM is valid for 5 years from the "Model Epoch" parameter given in decimal years." Thankfully the fractional part of model epoch has been .0 for at least a decade and so the date calculated from the start of the year always came back as the correct January 1 of the epoch year. I happened to notice the incorrect date handling when requested to provide the epoch date out of the code that replaced the older c++.

• Solw Purpose Of Visit (unregistered) in reply to King

I'll bet you haven't done PO-CORAL, though. And I'm practically certain you haven't used GEC4000 assembler (I think I have the GEC model right.)

The lovely thing about the GEC runtime environment (back in the day) was that the tools deliberately left about 32 bytes at the end of each code page, so you could plug in some assembler to patch a mistake in the original PO-CORAL.

Well, I say "lovely." As HST said, "I don't recommend drugs and violence to anyone. They just happen to work for me."

• Solw Purpose Of Visit (unregistered)

(As an aside, and I just learned this from Wikipedia, apparently Queen Elizabeth II sent the first ever email from a head of state on … a GEC4080, using a program written in Coral66. I feel that this validates the entire early portion of my career …)

• eric bloedow (unregistered)

somehow this made me think of a "dumb criminal story": someone tried to make a fake ID, but wrote "FEB 32" as the birth-date.

Yeah, that's the Linux problem with documentation too. You go search for the answer to something and you will find 12 different answers on how to do it, and any answer that wasn't written in the last month probably no longer works. The only thing worse than no documentation is lots of wrong documentation!

• markm (unregistered)

@Just Me: "Also note that a human decides when to invoke leap seconds, so there's no computer function for calculating them."

It's worse than that. Leap seconds compensate for variations in the rotational speed of the Earth, which are measured, not calculated or predicted. To predict or calculate this, you would have to factor in the moon, sun, the planets from Mercury to Jupiter (at least), shifts in ocean levels due to wind and barometric pressure, and movements in Earth's liquid core. The astronomical influence is difficult to calculate even with supercomputers. The meteorological influence is unpredictable. The liquid core inputs are unknown.

The human decision-making is exactly when to insert the leap second given an almost-one-second discrepancy. This could be reduced to rules and numbers and automated, but a program that cares about leap seconds would still have to go out on the web and download the measurements of the discrepancy. It would still be easier to just look up the leap-second schedule. For most purposes, it's sufficient to periodically check the calendar date/time on-line

• Chipsa (unregistered) in reply to Z

The defense industry is one where garbage collection of memory is done by destroying the computer it's running on (and incidentally, the missile).

• (nodebb) in reply to markm

It's worse than that. Leap seconds compensate for variations in the rotational speed of the Earth, which are measured, not calculated or predicted.

The usual fix (for applications that don't need that much accuracy, which is most of them but not all) is to stretch the civil second slightly when that happens so that the error is corrected over the next few hours. This isn't a much larger correction than you actually have to apply to handle variations in temperature of the cheaper oscillators; it's not a big deal! The bonus is that every day has the same number of seconds (ignoring timezone changes, which you should; timezones are controlled by politicians who can't leave well alone!) and that enormously simplifies a lot of other calendrical calculations.

• eric bloedow (unregistered)

"Tredecimber" reminds me of Piers Anthony and his silly "ogre calendar" with weird month names like "januwary" "febuweary" "noremember" "dismember", and more i don't actually know.

• Steve Taylor (unregistered) in reply to Solw Purpose Of Visit

And, of course, the GEC-4000 assembler (called Babbage) is the best assembly language ever invented and I have no idea why other vendors haven't copied the concept.

• (nodebb)

Decimal time is not new...StarDates anyone?