Interesting scenario of how a bug happened at a big e-commerce company.

This happened about 10 years ago and an engineer got the requirement to send datetimes to an integration endpoint. Those datetimes were going to be used in a number of different ways, some related to the delivery of orders.

The engineer knew the recommended way to encode datetimes was to use ISO-8601, a standard first published in 1988 that stipulates the datetime's representation format as YYYY-MM-DDThh:mm:ssZ and a few variations to include timezone. This is the standard used in Salesforce.

However, he was told he should use the company's standard, which was epoch time - also known as Unix time - which is the number of seconds elapsed since 1/1/1970 at midnight UTC. That is a good representation to calculate durations and other operations with datetimes.

He had the intuition that straying from the standard would cause problems but didn't know what they could be. He coded a few tests for the scenarios he could think of and hoped for the best.

The first bug was revealed when delivery drivers would schedule their shifts for future dates, but only during vacation. Why?
It must have been a bear to find out: the driver on vacation was in a different timezone when scheduling the future delivery.

The other bug was when scheduling deliveries before daylight savings changed.

Both these would throw the schedules off.

The moral of the story: there are reasons for "best practices" even though you may not be able to think of them at the time.

Learn about the Chesterton's Fence concept.