Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2020 Leap Day Bugs

codeofmatt.com

Post reply on HN
Print view View original

31–40 of 150 posts

Re: 2020 Leap Day Bugs

#31

Post by Misdicorl »

burfog wrote: post #24
Misdicorl wrote: post #16

Earlier quoted context omitted.

Almost all the edge cases with time have to do with localization. Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. Adjust above sentence to reflect the level of precision and range your use case needs. You are now done for 80% of use cases (perf timing, logging, timeouts, event storage, event ordering within jitter). If you need to parse/display for hum…

You can still have problems. It may be determined that the computer's clock got too far ahead. For example, it booted and you cared about time, but NTP hadn't yet made corrections. Suddenly the time runs backwards. Leap seconds may get interesting too, especially if you have to predict ahead or if the OS isn't updated often enough. (there is a 6-month warning) If you want to call leap seconds an issue for humans, the…

Leap seconds are only a problem for wall clocks (localization) and deciding whether to call something utc or tai.

The ntp case is contrived. Either you care and wait until ntp has connected to do your stuff. Or you care and don't let ntp rewind and instead smear. Or you don't care and deal with the consequences.

Re: 2020 Leap Day Bugs

#32

Post by Misdicorl »

ken wrote: post #28
Misdicorl wrote: post #16

Earlier quoted context omitted.

Almost all the edge cases with time have to do with localization. Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. Adjust above sentence to reflect the level of precision and range your use case needs. You are now done for 80% of use cases (perf timing, logging, timeouts, event storage, event ordering within jitter). If you need to parse/display for hum…

Your percentages are backwards, IME. Timeouts and logging and such are definitely not “80% of use cases”. Interfacing with humans and human systems are.

I disagree. Time is pervasive and will exist in every application in some way. It will only matter to the user in a small subset of them

Re: 2020 Leap Day Bugs

#33

Post by user982 »

phoobahr wrote: post #8
user982 wrote: post #4

A line in one of my Python daemons has been crashing it repeatedly all day: isotime = datetime.strptime(time.get('title'), '%a %d %b %I:%M:%S %p').replace(year=YEAR, tzinfo=TZ).isoformat() ValueError: day is out of range for month It's not mission-critical, so I'm just going to wait it out until tomorrow. EDIT: Hacked it out. isotime = datetime.strptime(f"{time.get('title')} {YEAR} {tzoffset:+03d}00", '%a %d %b %I:%M…

That strap time parsing doesn't fail under python 2.7.17 or 3.8.1

  Python 2.7.17 (default, Dec 31 2019, 23:59:25) 
  Type "help", "copyright", "credits" or "license" for more information.
  >>> from datetime import datetime
  >>> datetime.strptime('Sat 29 Feb 12:00:00 PM', '%a %d %b %I:%M:%S %p')
  Traceback (most recent call last):
    File "", line 1, in 
  ValueError: day is out of range for month

Re: 2020 Leap Day Bugs

#34

Post by FreeFull »

onei wrote: post #29
ge96 wrote: post #23

Earlier quoted context omitted.

what does this mean? you're okay if you're using 64bits? just briefly skimmed the 2038 wikipedia page, mentioned 32bit

If you store time as seconds since the Unix epoch (1st Jan 1970), you'll overflow a 32 bit unsigned integer in 2038 (around March iirc) and time will suddenly be back in 1970 again. I believe the Linux kernel did some work to circumvent this on 32 bit systems in a recent release, but if you're running an old 32 bit system you're probably out of luck.

Actually, it's signed 32-bit integers that overflow in 2038. Signed integers have been used because people wanted to store dates earlier than 1970 too.

Re: 2020 Leap Day Bugs

#35

Post by btmiller »

LinkedIn has one! Yesterday it listed my time with my current employer as 2 years and 9 months. Today, it’s 2 years and 8 months! Can anyone venture a guess on how I time traveled?

Re: 2020 Leap Day Bugs

#36

Post by detaro »

user982 wrote: post #4

A line in one of my Python daemons has been crashing it repeatedly all day: isotime = datetime.strptime(time.get('title'), '%a %d %b %I:%M:%S %p').replace(year=YEAR, tzinfo=TZ).isoformat() ValueError: day is out of range for month It's not mission-critical, so I'm just going to wait it out until tomorrow. EDIT: Hacked it out. isotime = datetime.strptime(f"{time.get('title')} {YEAR} {tzoffset:+03d}00", '%a %d %b %I:%M…

Interesting. Given the documentation of strptime, I would have expected that to not be possible at all (since constructing a datetime without a year isn't possible directly)

Re: 2020 Leap Day Bugs

#38

Post by IggleSniggle »

maxerickson wrote: post #27
jrandm wrote: post #20

Earlier quoted context omitted.

I believe accurately conveying identical information in a manner everyone can understand is an impossible, or at least unreasonable, burden to place on individuals. Instead, what if people tried to hear graciously and "assume good faith"? The quote is ripped from HN's guidelines.

Can you please explain more about how your response relates to my comment? For instance, I've not placed the burden of "conveying identical information in a manner everyone can understand" on anyone, nor have I assumed bad faith. So it seems like a weird comment to tack onto mine, but I am assuming I just don't correctly understand.

Hyperbole and precision can get tricky in human language because different cultural groups have different language encodings for the same sets of words.

For example, if you live in London then "9 in the morning" means when the world synchronized clocks agree that, locally for you, the time is 9am. But if you say "9 in the morning" to someone in Belize, it means "first thing after you are finished with your morning and ready to start your day," which can mean 1pm in some cases.

Here's a lovely article on these kind of time-keeping differences, around something that you might expect to have a precise meaning:

https://www.businessinsider.com/how-different-cultures-under...

More to the point at hand, however, you suggested that people not speak in hyperbole but instead speak accurately. Although you can request that others adjust their use of language while in your presence to better meet your needs for a certain kind of precision, policing other people's language isn't possible. However, re-interpreting what people say into what they mean is somewhat possible for an astute listener who understands the context.

Re: 2020 Leap Day Bugs

#39

Post by mytailorisrich »

Misdicorl wrote: post #16
hmate9 wrote: post #2

This is why no one should ever ever write their own Time or Date library. The number of edge cases is simply enormous

Almost all the edge cases with time have to do with localization. Build your time library on (un)signed 64 bit integers representing the number of nanoseconds since the utc epoch. Adjust above sentence to reflect the level of precision and range your use case needs. You are now done for 80% of use cases (perf timing, logging, timeouts, event storage, event ordering within jitter). If you need to parse/display for hum…

I've come to the same conclusion as you: Keep time as a purely monotonic integer for everything and convert that as needed to display to humans.

This also pushes all the madness to the edges and out of the business logic.

That being said, this works well for applications that are not "date intensive" so to speak. If your business logic has to deal specifically with calendar dates, e.g., monthly events, then you have to deal with calendar months and all that this involves, including explicitly dealing with the 29th February.

Re: 2020 Leap Day Bugs

#40

Post by ehsankia »

hmate9 wrote: post #2

This is why no one should ever ever write their own Time or Date library. The number of edge cases is simply enormous

It's not only about writing your own library though. For example, it's often not reading the documentation properly.

In Python, if you take a datetime, and call .replace(year=X) on a datetime for Feb29, it'll throw a ValueError.

Post reply on HN