101–110 of 212 posts
Earlier quoted context omitted.
I hereby announce my campaign for the role of Time Druid.
Your symbols of office shall be a blinking 12:00 and the date 01-01-1970. Wait. In fact, if you weren't born on 01-01-1970, you can't be Time Druid. Sorry.
The biggest falsehood a programmer could believe about time is that they have the ability to roll their own time manager. Just use a battle-hardened library and hope for the best. Dealing with time in code is crazy-making in a way I never expected.
Would love to hear some horror stories you've encountered. It might help me keep an eye out for it.
One of the hardest programs you could ever have to write would be historical times taking into account all the time zone and Daylight Savings Time changes over the years. It might be impossible. Just look at Indiana's history with time zones and DST.
I did not fix that bug. (But I did learn that the 'TZ' database has this information, though I think 'America/Indiana/*' had been pruned out of the copy our JVM was using.)
10 AM
11 AM
12 PM 01 PM 02 PM
03 PM
I see large software systems for things like airlines and trains sometimes make this mistake, for instance a 1 hour trip on a ticket that says "11:30AM - 12:30AM" which is actually negative 11 hours.
I have a collection of photos somewhere of every time I've caught it. If I could change anything about time that probably nobody would care about, it would be to align those two cycles.
The fact that I catch it every couple months on widely deployed systems I interpret as the signal that basically nobody notices/cares about it as everyone knows a -11 hour train ride isn't how time works.
Yes, good. But not all applications need a “platonic ideal” understanding of time. Often when you type just the code you need, the system performs excellently, and the code is minimal.
We should just define a year to be 360 days long and made up of 12 30 day months. Then we can elect some druids or whatever to arbitrarily, at the start of each year, define which dates the seasonal borders will land on. Events which are truly dependent on weather can be defined in terms of "Days after the season starts." Or we could define a 5.5+-.5 day holiday between the beginning and end of a given year. Those da…
https://qntm.org/calendar See also: https://qntm.org/continuous and https://qntm.org/abolish
> having one or two days per year which are part of no month is stupid
which I've cleverly circumvented by adding almost a while week. I believe in this case the stupidity overflows and it becomes a good plan again.
The biggest falsehood a programmer could believe about time is that they have the ability to roll their own time manager. Just use a battle-hardened library and hope for the best. Dealing with time in code is crazy-making in a way I never expected.
If you actually need to worry about calendars and user input, you have my sympathy.
- `pytz.timezone(timezone_name)` will give you the current offset for that timezone - well, it will at least be some consistent offset - surely, every timezone has the same reference starting point?
What `pytz.timezone(name)` actually does is initialize a timezone object at the point in time of the first entry in the tz database for that zone. For example, New York had an offset of 4:56:02 prior to 1883 November 18, 12:03:58 [1]. That is the "starting point" for America/New_York and US/Eastern (which I think is an alias of New_York before a certain date). Which is why you get
>>> pytz.timezone('America/New_York')
>>> pytz.timezone('America/New_York').localize(your_specific_datetime)
[1] https://en.wikipedia.org/wiki/Tz_database#Example_zone_and_r...
>Leap years occur every 4 years. Isn't leap year calculation one of the very first things you do in most programming tutorials/schools? I know that a lot of people don't know this, but most programmers should, r-r-r-right?
If you handle dates and times yourself on that level, prepare to be in a world of pain. Handling time and dates correctly has a similar difficulty to writing your own cryptographic primitives: If you don't know exactly what you are doing you will shoot yourself (and potentially countless others) into the foot at one in point or another.
I find this simplified date/time very useful, unless you have to manage “continuous and/or real” time somehow. 99% of applications are okay with it, because they’re facing users with exactly the same mental model. Also, albeit not correct scientifically, it reflects many developers’ mental model as well. This is much better than a model that just doesn’t match, which is a world of pain. Someone adds 86400 but it’s the same day, good luck debugging it.
I don’t think this is a cryptographic-level issue.