
Falsehoods Programmers Believe About Time (2012) - kushti
http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
======
rdtsc
I got two I noticed over the years:

* Didn't think about time at all.

In most cases most don't think about time until it becomes a problem. It often
ends up with a system which behaves in surprising ways, and is the equivalent
to the developer believing any of those things in the article. But there is a
difference in them believing those falsehoods, and simply not being a aware of
them at all.

* Time moves forward

This is probably the biggest gotcha of all. Just imagine how many times int
the past you did dt = now() - t0, then did something with dt like sleep(dt).
Well time will move backwards sometimes and dt is negative. I bet this will
make most people here worried and they'll think about code they wrote like
that (sure did). I have seen systems freeze for example because they end up
sleeping for a huge amount of time (negative number was cast to an unsigned
huge number).

A small advice on how to improve errors related to time is to abstract it away
from algorithms and code as much as possible. Instead of always calling
gettimeofday() / time() / now() function to get the current time, in a piece
of lower level code, try to pass it in as an argument. That will make code
testable.

I have seen fun failing test cases. Something like encoding the current time
the test was written and a dt to current time. The test was working for years
then started failing eventually because of the hard coded time.

~~~
rubber_duck
>Instead of always calling gettimeofday() / time() / now() function to get the
current time, in a piece of lower level code, try to pass it in as an
argument.

Any code that uses time based scheduling should use a virtual implementation
of time/scheduler to allow testing - this way you can say "sleep 10 hours" and
then "move virtual time by 10 hours" and actually verify that the timeout is
hit without the tests actually taking 10 hours. It also lets you test out
logical edge cases such as `<=`, `>=` vs `<`, `>` which is surprisingly tricky
with timeouts.

~~~
porker
Great idea! But how does one make a virtual implementation of time/scheduler?

~~~
edejong
Every function which returns the current time, should be dependency injected
with a 'currentTimeService'. This service, during tests, is injected with your
mock implementation, and during production with a simple call to 'new
DateTime()' or sth like that.

~~~
hermannj314
I 100% agree.

I've pitched this before (during a code review for something) and was laughed
at by the team under some guise of YAGNI / developer gold plating. They
honestly thought I was joking. Once I explained the issues mentioned in the
article, they still thought it was a waste of time.

It takes just a few seconds to implement and makes the code so much easier to
test / maintain.

~~~
edejong
Tell them we're currently replaying test scenario's involving thousands of
truck routes per day (and around a thousand trucks). This allows us to easily
recreate bugs and see the effects of fixes, new algorithms, etc. etc. Couldn't
do it with some DI on the whole system and simulated time.

------
Animats
Leap seconds are a big enough problem that stock markets shut down for
them.[1] Google starts advancing their clocks hours in advance of a leap
second. Power companies take about four hours to catch up after one. (Every
1800 RPM generator has to make 30 extra turns.) Very few systems properly
handle a 61-second minute. Unix timestamps are fundamentally incompatible with
leap seconds.

[1] [http://money.cnn.com/2015/06/29/technology/leap-
second/](http://money.cnn.com/2015/06/29/technology/leap-second/)

~~~
sparky_z
"Every 1800 RPM generator has to make 30 extra turns."

I'm having trouble wrapping my my head around this one. If the goal is
maintaining a steady output, shouldn't they keep revolving at the same rate,
without worrying about what day the "current" second (no pun intended) belongs
to? After all, I'm assuming they don't "catch up" after leap days, they just
run for an extra day at the same output level. Why would leap seconds be
different?

Put another way, what do they need to spread those extra 30 turns over a 4
hour catch up period? Weren't they given an extra second in which to take care
of them?

~~~
dlgeek
A lot of systems use the 60hz (or 50hz depending on location) signal from AC
power as a way of keeping time. It's used enough that power companies will
actually adjust the frequency minutely at night in order to make up for any
mistakes made during the day. (Which in turn makes it so reliable that more
systems use it to track time, and so on...)

I guess grandparent post is saying power companies go ahead and feed in extra
cycles for the leap second. It's not something I'd heard of, but it wouldn't
surprise me.

~~~
Angostura
Hmmm? In the UK I'm sure the frequency changes with load on the grid and is
actually a way of measuring grid load.

~~~
anexprogrammer
Indeed, and they have to remain within +-1%. They have a realtime graph:

[http://www2.nationalgrid.com/uk/Industry-
information/electri...](http://www2.nationalgrid.com/uk/Industry-
information/electricity-transmission-operational-data/)

Before quartz clocks were around, synchronous mains clocks were common, and
accurate.

------
amelius
Falsehood non-physicists believe about time: simultaneity.

[https://www.youtube.com/watch?v=wteiuxyqtoM](https://www.youtube.com/watch?v=wteiuxyqtoM)

------
po1nter
This is a very interesting video by Computerphile on this subject:
[https://www.youtube.com/watch?v=-5wpm-
gesOY](https://www.youtube.com/watch?v=-5wpm-gesOY)

------
MarkMc
My experience is that for most applications, programmers really only need to
understand 3 types:

1\. An instant in time - often represented as an integer number of
milliseconds since January 1, 1970.

2\. A date in the Gregorian calendar. This could also be an integer offset
from a particular day, but it's better to encapsulate it in a class that
allows you to add days or months, get the number of days between two dates,
etc.

3\. A timezone which is necessary to convert between the two types mentioned
above.

Java has default classes to represent Types 1 and 3, but is missing a simple
class for Type 2. So I designed one myself:
[http://calendardate.sourceforge.net](http://calendardate.sourceforge.net)

~~~
edejong
I think the following ingredients are minimally necessary for normal day-to-
day stuff:

1\. For events in the past, a timestamp

2\. For events in the future, a date/time pair with precision at least
milliseconds and a timezone.

3\. An ISO 8601 serialization/deserialization method

4\. A duration type, which denotes a number of
'hours/minutes/seconds/days/weeks'.

5\. A partial representation of date, to denote repeating events or events
which last a whole day. The partial representation should optionally include a
timezone. This allows me to say: '5th of May', or '22nd of November 1980, in
CEST'.

For calculations of dates and times, it is very useful to have a notion of
time intervals, durations of time and weekdays.

~~~
MarkMc
> For events in the future, a date/time pair with precision at least
> milliseconds and a timezone.

Hmmm...Can you give an example where that would be used? I'm thinking of a
user who wants to be woken up at 7am even if they change their timezone. But
that wouldn't require millisecond precision.

> A duration type, which denotes a number of
> 'hours/minutes/seconds/days/weeks'.. For calculations of dates and times, it
> is very useful to have a notion of time intervals, durations of time and
> weekdays.

Couldn't you do that with the first two types I mentioned? With two instances
of Type 1 it's trivial to count the number of milliseconds between them. With
two instances of Type 2 you can have d1.daysUntil(d2) or dq.monthsUntil(d2)
etc.

> This allows me to say: '5th of May'...

Is that common enough and complicated enough to warrant an extra type? When I
write code to process credit card payments, I just record the card expiry as
two integers: expMonth and expYear. When I want to check if the card is
expired I just create a Type 2 instance representing the last day of the
month. Seems to me I could do something similar for 'repeat on 5 May'.

~~~
tomjen3
For the first example, a skype meeting with participants on both sides of the
equator, or even just in countries where one has ended daylight savings time
and the other hasn't yet.

That may seem like a special case, but it is relatively common, it might also
matter for normal business meetings in a foreign country - UK time is an hour
behind France, so if you are a UK business man trying to have a meeting in
Paris, you need to take time zones into account.

It is never trivial to calculate the duration between two times, because you
may have to take into account leap years, leap seconds, months that does not
have the same number of days, etc, not to mention if they are in two different
timezones. That doesn't mean it isn't possible, but it is not trivial.

What is the last day of the month? That depends on the month, and if that is
February it also depends on the current year. If you need to process credit
cards, you might need to know the last banking day of the month, which could
be quite early during e.g easter. BTW to know when easter falls, your dating
system needs to know about the lunar calendar.

This doesn't even begin to touch what happens in countries that celebrate
Ramadahn.

~~~
MarkMc
Those are some interesting situations, but I think they can still be handled
using the 3 types I mentioned.

A Skype call is actually a good example of when _not_ to use a data type which
encapsulates 'time zone plus instance in time'. That's because there is not
one but multiple time zones associated with a single instance in time - each
Skype caller will have his or her own time zone. The time of the call should
be treated as a pure 'instance in time' without reference to any particular
time zone. When it comes to displaying the time to a particular user, you
would have formatting code which takes (a) the user's time zone; (b) the
user's language; (c) a format pattern; and (d) the instance in time; and
returns (e) a string representation of the time for that user.

If the computer's clock is based UTC it _is_ trivial to find the duration
between two 'instants in time': it's just t2 - t1. An instant in time (what I
called Type 1) is independent of any calendar system so months, leap years,
time zones, etc. don't matter when calculating the duration between two Type 1
values.

However, in practice most system clocks are not based on UTC but rather Unix
Time [1]. Due to leap seconds, such clocks do not always 'tick' in a monotonic
way. So I accept that it is usually not trivial to accurately find the
duration between two times. But the solution is not to burden the programmer
with an extra type - instead, just add a method to the existing 'instant in
time' class like this: t1.millisecsUntil(t2).

To find the days in any given month, a 'date in the Gregorian calendar' class
(what I call Type 2) can handle that easily - just call the daysInMonth()
method. Again, no need to create new type.

Easter, Islamic dates, Buddhist dates, banking days, etc. are all based on
Type 2 - ie. an abstract concept of a 'day' without reference to any time zone
or any particular instant in time.

[1]
[https://en.wikipedia.org/wiki/Unix_time](https://en.wikipedia.org/wiki/Unix_time)

~~~
edejong
The Skype call is always in reference to a certain perspective of 'time-of-
day'. So, you'd say: I will call you at 13.00 CET, which is 14:00 GMT at my
place. When we move it to the next day, it will be in reference to CET and DTS
will be taken into account in CET, not in GMT. As long as humans see time as a
location dependent aspect, it makes sense to inform them of the reference that
has been used (being the timezone). Another way to say this is that the Skype
call, or the appointment, will be scheduled at a time and timezone of
someone's perspective. The other participants need to see the appointment in
reference of that.

The duration in milliseconds is (almost always) easy to find. However, you
often want to find the duration in months, weeks, days, etc. etc. This again
requires a reference timezone and calendar system.

Your 'type 2' day is actually very difficult to define. For example, when I
talk about the 12th of October 2016, I will see it as a time-interval in
central European time. Your time-interval might be different. By the way, you
can only handle the daysInMonth case. Other examples would fail: weeksInMonth,
weeksInYear, hoursOfMonth, etc. etc.

------
inlined
My favorite time-related false beliefs are about time zones:

1\. 1AM happens 24 times a day

2\. Ok, so 1A is screwed up because of DST. Noon happens 24 times a day.

3\. The maximum distance between time zones is 24 hrs

4\. Time zones are in 1hr increments

5\. In half hour increments?

6\. UTC offset is a good thing to store in someone's profile

7\. People live in a fixed number of UTC offsets

~~~
jaggederest
Add to it:

Time zones change linearly from east to west and west to east

For each physical location there is exactly one time zone

~~~
77pt77
> For each physical location there is exactly one time zone

Care to elaborate?

~~~
Crespyl
I don't know of any parcels of land that are simultaneously in more than one
zone, but I do know that (until recently?) Indiana used to change time zones
from Eastern to Central instead of using DST.

~~~
77pt77
I knew that.

What I understood was same geographical location with several time-zones at an
instant in time.

Modulo border disputes I don't know of any such thing.

~~~
jaggederest
There are several places on earth that have an official and unofficial time
zone, chiefly on time zone borders - some places in Indiana, for example, and
the far western part of China where the time zone varies from solar time very
significantly.

In those places, if you ask a user where they are, and then show them a time
zone based on that, it may not reflect what they think.

------
calanya
That the clock always moves forward.

As one example, some clocks are cpu specific (rather than system specific).
When a thread gets scheduled to a different cpu, it might be talking to a
different clock, and getting a backwards time.

The user might also be changing the clock while the program is running, of
course.

If the forward direction of time is important, make sure the the source of
time is a monotonic clock API.

~~~
saretired
All I can add is a warning about running NTP if you are maintaining a priority
queue of time-stamped actions (now + delta, where delta depends on the
action): use CLOCK_MONOTONIC instead of wall time.

------
tracker1
One recently that bugs me to no end, is someone at the company I work for
created an API that takes a date parameter in YYYY/DD/MM format... wtf?!?
YYYY-MM-DD is fine, when year is first, the month should _always_ be next...
that's universal at this point. mm/dd vs dd/mm is a problem, but it's always
ymd when year is first. _sigh_

The issues with timezones, and offset calculations can be problematic too...
fortunately most environments and language platforms have systems in place to
at least convert to/from local to utc, while that doesn't resolve for time
drift, or mis-set times, it does handle a lot of issues to _always_ use utc,
or use date/time + location if not using utc...

Another hard one is leap minutes/seconds, daylight savings time changes, etc.

~~~
nojvek
In US a lot of paper forms use yy-mm-dd. America has crazy units and
standards.

~~~
tracker1
US is MM/DD/YYYY for most paper forms... whenever year is first, it's always
year-month-day, period.

------
Arnt
Time education in practice:

The linux kernel boots 5 minutes before the end of time, so that anyone whose
code would break when jiffies wraparound will see that breakage soon after
boot. That's a great, great feature.

~~~
kedean
Out of curiosity, what does the kernel consider 'the end of time'? Int 64
maximum?

~~~
Arnt
uint32.

------
deathanatos
I discovered this one, recently:

> _Excel stores dates as sequential serial numbers so that they can be used in
> calculations. By default, January 1, 1900 is serial number 1, and January 1,
> 2008 is serial number 39448 because it is 39,447 days after January 1,
> 1900._

That's from the Microsoft's documentation of Excel[1]. Note this part:
"because [Jan 1, 2008] is 39,447 days after January 1, 1900"

    
    
      In [3]: (datetime.datetime(2008, 1, 1) - datetime.datetime(1900, 1, 1)).days
      Out[3]: 39446
    

Off by one, Microsoft. And yes, Excel does the same thing — i.e., the docs
match the product.

If you're wondering why, it's b/c Excel incorrectly thinks that 1900 is a leap
year. (Also, this is why a lot of Window's clocks track time since 190 _1_ ,
as it makes leap year calculations simpler… for now.)

[1]: [https://support.office.com/en-us/article/DATEVALUE-
function-...](https://support.office.com/en-us/article/DATEVALUE-function-
df8b07d4-7761-4a93-bc33-b7471bbff252)

~~~
ufmace
I recall reading somewhere on Joel on Software that I can't find at the moment
that Microsoft did this deliberately to duplicate a bug in Lotus 1-2-3,
because they needed perfect compatibility with formulas and dates with 1-2-3
to get people to switch over. And Lotus 1-2-3 reportedly had this bug because,
at the time it was written, the code to account for that case correctly
legitimately took up too much space and was dropped, with Lotus figuring that
not too many people would notice. And of course, Microsoft can't change it
now, or else they'll potentially break a ton of people's spreadsheets that
already work around it.

------
MatthewWilkes
I had some fun ones a couple of years ago on this theme:

* Every week has a weekend

* Weekends are always Saturday and Sunday

* Weekend days never change within a locale

* Weekend days are always on consecutive days

~~~
emddudley
Are you talking about historical dates and calendars, or maybe different
cultural calendars? Could you provide some examples? In the US today I don't
think these four falsehoods are ever false.

~~~
falcolas
I imagine the concept of weekends, as related to most computing, has to do
with a work schedule.

Back when I used to work the night shift on non-standard days, doing any kind
of scheduling with an electronic device was a real pain. Even today many
scheduling tools don't cope well with overnight meetings.

------
btbuildem
Let me just throw Easter in there, since nobody else has..

[https://en.wikipedia.org/wiki/Computus](https://en.wikipedia.org/wiki/Computus)

[http://aa.usno.navy.mil/faq/docs/easter.php](http://aa.usno.navy.mil/faq/docs/easter.php)

------
BurningFrog
One thing I've had to explain to many programmers, at several different jobs:

* A timestamp is not a date.

Many people believe a timestamp is a "more detailed date". In reality, every
timestamp is in (at least) two different dates, depending on what timezone you
look at it in.

The terrible java.util.Date is probably one reason.

------
ZoFreX
I have two suggestions, one useful and one less useful:

1) Given two events that happened in two different locations, one happened
before the other or they happened at the same time [1]

2) All the devices comprising your system will agree on what offset each
timezone is (alternatively: will have the same version of the tzdb)

Number 2 is not a theoretical problem: if you have users in a country where
the timezone can change at short notice (e.g. Turkey), how do you handle the
fact that across all the different Android versions their phones will have
different opinions on what the time is and what timezone they are in?

[1]
[https://en.wikipedia.org/wiki/Relativity_of_simultaneity](https://en.wikipedia.org/wiki/Relativity_of_simultaneity)

~~~
GeneralMayhem
(1) is not a theoretical problem in distributed systems. I work on a system
that involves malicious actors such that allowing subtle timing problems can
cause very real revenue impact, and defining consistency in a way that
converges quickly with only what amounts to a vector-clock definition of time
is tons of fun.

~~~
ZoFreX
I was deliberately careful with the wording - yes, in distributed systems, we
may be unable to determine which event came first. But one of them did happen
first in reality, we just can't tell which. However, in some cases (see the
Wikipedia link) it's not even true that one of them did happen first - it
depends on where you observe them from and there is no definitive answer!
Relativity is weird.

------
imagist
A case like this, which has a wide variety of exceptions that need to be
updated as timezones change (yes, they do) is a perfect case for a library.
The best I've ever found was JodaTime, but I no longer work in Java and no
other language has an equivalent.

~~~
huherto
Joda Time was "adopted" as a part of java 8 on the java.time.* packages.

~~~
imagist
Yeah, but that happened to late to help me. :/

------
partycoder
Dates and times, floating point numbers, even strings... there will be always
magic in how data is represented/encoded.

Now in the case of dates, there's the epoch, and a precision determined in
terms of that epoch, there are compatibility workarounds between 32-bit and
64-bit time... we add have leap days and leap seconds, and of course: the fact
that clocks go out of sync, timezones and daylight saving time, as well as a
long long list of things.

Some countries move dates for DST every year.

Then, there are days that "do not exist" (September 1752 in UK/US, etc, when
they moved from the julian to the gregorian calendar).

------
okket
Previous discussion:
[https://news.ycombinator.com/item?id=4128208](https://news.ycombinator.com/item?id=4128208)
(4 years ago, 213 comments)

------
splicer
For iOS devs: mach time is just a more precise, monotonic equivalent to
wallclock, and it never pauses :p

See
[https://developer.apple.com/library/content/technotes/tn2169...](https://developer.apple.com/library/content/technotes/tn2169/_index.html)

------
huherto
It looks like some of these should be taken care on the operations side. Sort
of like [https://12factor.net/](https://12factor.net/)

As a programmer you need to be able to make assumptions, otherwise it gets
crazy complicated.

------
cwmma
This list seems to imply relatively is only important orbiting black holes but
the GPS satellites are far enough from earth or orbiting fast enough (both
apply to satellites depending on orbit height) that relatively applies and the
clocks have to be adjusted.

------
novaleaf
if you think dealing with time is a problem, try measuring elapsed time on
computers that sleep :)

the solution i found (when dealing with this problem in C# a few years ago) is
that you need to poll the time in an update loop (running at, say 10hz or
whatever resolution you need). if you have a sudden jump in time between two
loops, chances are the computer was asleep.

or there was a leap second.

or you are sampling local time instead of UTC and daylight savings just
occurred, or the user crossed timezones.

or the user changed their clock manually.

Or the computer resynced with the time server (happens quite often, and can
cause negative time to elapse. Better check the CPU for elapsed ticks
instead!)

man... this is starting to sound like roll-your-own-cryptography ;)

------
mofle
More interesting falsehoods in this awesome list:
[https://github.com/kdeldycke/awesome-
falsehood](https://github.com/kdeldycke/awesome-falsehood)

~~~
dredmorbius
Nice. Includes the one I'd just posted as well.

I recommend submitting that to HN. Looks as if it was a couple of months ago,
but definitely worth the resubmission as it didn't take:

[https://hn.algolia.com/?query=https:%2F%2Fgithub.com%2Fkdeld...](https://hn.algolia.com/?query=https:%2F%2Fgithub.com%2Fkdeldycke%2Fawesome-
falsehood&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

------
abc_lisper
Much needed. Thanks. Handling time is difficult, and Java's api(older ones)
didn't make life easy. I have fixed many subtle bugs in my code related to
time, over the years.

------
tmaly
I have had my fair share of dealing with these over the last decade.

pulling data from processes that run in different timezones and trying to
merge that all together has been really fun.

------
bmh100
I appreciate the list of things to look out for, but what about solutions?
That would increase the value of the article immensely.

------
sammorrowdrums
Also: * Leap years occur every 4 years

~~~
sammorrowdrums
* Timezones never change

------
Balgair
I've got 2:

-Your clock works the way you think it does

I was working for a company that makes pico-second clocks. It turns out, that
all clocks experience drift. Like a gyroscope, each clock has it's own
peculiarities and hyper-local environment, and like a gyroscope, they all tend
to record and count time in different ways. If you have a clock, you know what
time it is. But if you have 2 clocks, you are never sure. Now, we extend this
to many clocks and we then have an ensemble of them, and (thank god) it ends
up being a normal distribution that we then take the mean of. Now with
picosecond clocks, the local gravitational environment, temperature, wear
history, etc all end up being very big factors in time keeping. For most
systems, this would be a catastrophe. You'd have to bury the clocks in some
mountain, gravitationally 'shielded' away from things, temperature controlled,
super clean, etc, and only take the time once a day or something. It turns out
that if you run those calculations, you can only keep time to a part in
10^-16. Fortunately though, we discipline time to that of the Earth. Days and
years are the thing we must subside to. And these things are only good to
about a part in 10^-12, so we have 10,000 parts of 'error' to live in. It
turns out, the Earth is a pretty bad clock, overall. It was pretty cool, years
after I left that job, to walk into NIST and see an ensemble of our old clocks
in the room where the US second is measured.

-Leap seconds always occur on the same date/time of the year.

The terrible earth-quake in Fukushima really did a number on the international
timing community too. The change in distribution of mass of the Earth was so
much that it slowed the year down by ~1 millisecond in total. I hope that the
readers of the article and the rest of the comments here can appreciate that
such a change, though to a normal person is small, is actually quite a lot for
computers and other logic based systems. The 'leap-second', in reality a
millisecond, was chosen to occur not on the last night of February of the
following year, but was pushed forward to the last night of June. This did not
make the people that sell super precise clocks very happy. Typically, the
leap-second night is one of mayhem for clock sellers and the people that
support the sold clocks. As this usually happens at midnight, far past when
you have to put your kids to bed, the 'push notification' of the new time is
in weary hours. That means starting about 1 minute after midnight, you start
getting flooded with calls from your customers. Now, the purchasers of hyper-
precise clocks tend to be very wealthy and powerful and very angry and sleepy
that all of their very expensive computers are now 'all broke'd' in the
literal middle of the night. Most of the time, you can reach out to the IT
guys of these large oil&gas, Wall-Street, military, educational, and other
types of firms and make contacts and let them know things will start to get
out of whack. And they tend to learn that this usually happens in early March.
Well, for this end of June leap-second, we knew things were going to be hairy.
And they were. I was not even close to senior enough to be on those calls, but
I came in the next day and all the senior guys were STILL on the phones with
the various companies. When I left, they were on the phones still. I think
they must have been up for at least 50 hours, judging by the amounts of RipIts
scattered about the floors. That is what I call a salary job.

In all, I learned that humans think that time works in one way, but it really
is 'what a clock measures' and is an abstract concept we put a lot of value
into. And no, we will never be able to make a program that can take all of
these considerations into account. All that will do is make the
troubleshooting process a lot longer. Time is ephemeral, the Earth makes a bad
clock, and mammals are diurnal. Those 3 things make clocks and time-keeping a
'hands on' job.

------
dredmorbius
We could just cut to the chase:

Falsehoods programmers believe:
[https://encrypted.google.com/search?hl=en&q=%22things%20prog...](https://encrypted.google.com/search?hl=en&q=%22things%20programmers%20believe%20about%22#hl=en&q=falsehoods+programmers+believe+about+names&search_plus_one=form)

[http://www.metafilter.com/117073/Falsehoods-Programmers-
Beli...](http://www.metafilter.com/117073/Falsehoods-Programmers-Believe)

By way of lists, a pretty comprehensive one:
[http://spaceninja.com/2015/12/08/falsehoods-programmers-
beli...](http://spaceninja.com/2015/12/08/falsehoods-programmers-believe/)

More in another comment:
[https://news.ycombinator.com/item?id=12675830](https://news.ycombinator.com/item?id=12675830)

~~~
rurban
I miss falsehoods about pathnames:

* That there's never a \0 in a pathname

wchar names on MSWin UNICODE and WinCE. Symbian uses UTF16.

* That paths are seperated by /

Yes, Windows NT accepts /, VMS, VOS, RISC OS also, but MacOS classic had :,
and VMS uses []. And there are still \ pathseps only, like DOS, OS/2, SYMBIAN,
Novell NETWARE, AmigaOS4. Native Acorn RISC OS uses . as pathsep and : as in
DOS.

Just the easiest ones.

~~~
Bouncingsoul1
"* That paths are seperated by /" The day I learnded that Korean Windows
version uses a Won sign and Japanes use a Yen sign was very bad day.

------
saittam
And because time is so simple, we figured to just rely on accurate time for
TLS certificate validation and thus the security of HTTPS. </sarcasm>

------
GauntletWizard
Many, if not most of these things are problems with the environment, not
things programmers should think about or try to solve. In fact, most of them
should explicitly not be thought about. All that that will do is lead to
defensive programming - What if X happens? What if Y? The answer to most of
them is simple - Crash. Make it loud and clear that something is wrong. Any
attempts to rectify the problem, and most attempts to even detect it will only
add surface area to the code, surface area where you can screw up and
introduce bugs.

Could the system's timezone change? Yes. If you're manipulating time sanely,
you're already using a timezone aware time class - particularly when
serializing - and that's great. But if you're uncertain, it's best not to try
to rectify. Your program will never be able to guess with any success.

Almost all of this post strikes me as along the vein of the questions of
Babbage - "Pray, Mr. Babbage, if you put into the machine wrong figures, will
the right answers come out?" Almost all of these are the wrong numbers. Rather
than leading you to the simple, correct solution (Use good serialization
formats and timezone aware datastructures) it leads you down a path of
paranoia, convinced the world is out to get you. If you're programming for
that world, you're either a DRM programmer and should burn in hell, or you're
doing it wrong. Trust your environment and OS and make damn sure that when
you're setting up those layers you set them up right - Don't worry that every
second open() call will return an invalid filehandle, just because.

~~~
yoo1I
No.

Yesterday my friends Mac crashed hard while they were working on a foolishly
unsaved one-and-a-half page document in LibreOffice.

At the next start LibreOffice gives a big warning of "Oh shit things are
really wrong, should I fix them for you? [Continue | Cancel]" .

Thank you LibreOffice team for making it so that within the time of a phone
call to me plus the time it took to press "Continue" they were able to recover
the their document and continue working.

This "attempt to rectify" the problem, could only have made things better not
worse, so that's reasonable to implement.

I am not saying that _every_ problem needs a solution like this. But blanket
statements like "crash whenever there is a problem with your environment",
while certainly the correct way to do it in _some_ cases, leads to software
that's really shitty use if that's all the software does.

Because while

> Almost all of these are the wrong numbers.

is correct from a programmers point of view, we aren't talking about the
numbers a user put in, but rather numbers that the user has no control about.

And not many things are more annoying than computers doing unexpected things
for reasons that are incomprehensible to you.

~~~
gpderetta
>At the next start LibreOffice gives a big warning of "Oh shit things are
really wrong, should I fix them for you? [Continue | Cancel]" .

> Thank you LibreOffice team for making it so that within the time of a phone
> call to me plus the time it took to press "Continue" they were able to
> recover the their document and continue working.

Uh, that's exactly what the OP was advocating, if I understand correctly. On a
consistency check failure (i.e. an assert), crash immediately [1]. If the
application correctly handle transactional state changes, it will be able to
recover on startup from the replay log, as all changes are immediately
persisted on the log.

This approach is known as "Crash Only Software", and it is pretty much the
only approach for writing robust applications.

[1] Syncing the replay log to stable storage can be a good thing though.

~~~
GauntletWizard
Yes, and I'm consistently disappointed that HN no longer gets this - It's
becoming an echo chamber of those who can't and won't, rather than those who
architect and learn. Timekeeping considerations are rarely-to-never the
responsibility of an application programmer, and the scenarios presented -
Leap seconds, etc - Are either meaningless (Who cares if your delta-t value is
off by a second over a three month report?) or incredibly meaningful to the
point you explicitly define them in the spec (High-freqeuncy trading systems
should use good linearization mechanisms, not just rely on 'timestamp' \- The
programmers who are working on these problems have well documented that these
are hard problems that throwing more time specificity bits doesn't solve).

High level talks about low-level concerns are rarely helpful. This overview of
detailed problems without links or even understanding of the relevant
literature (It doesn't even mention the scenario that time runs backwards,
which is way more common and terrible than pretty much anything on the list).
This was a bad post, and it's bad training - Bringing up superficial questions
without giving places to check answers for sanity. Many people will likely
think about these issues halfheartedly, form half-baked answers, and propagate
mistakes. Good learning not only asks questions, but asks follow ups and helps
reach complete solutions.

