![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
juan_gandhi) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
dw_dev2024-01-27 04:52 pm
date range
I recently found I need to have dates in my posts before 01/01/1970. The reason being, I want to enter some diary records. I guess there may be other reasons for entering posts dated before 01/01/1970.
Had a discussion with support; they reasonably answered that 01/01/1970 00:00:00UTC is unix time zero.
The thing is, negative time does no harm; we can successfully go down to about Dec.13th, 1901 (as Wikipedia says). Maybe when we get closer to 2038, and 64-bit timestamps will make more urgent sense, we'll be able also to go down to ancient times, and record Roman or Egyptian history, but that's in the future.
I wonder how hard it would be to go ahead and widen the limits of timestamps. In my view, it must not be a big deal, right.
In our company, HealthExpense, now, unfortunately, nonexistent, we used this feature to mark patients dates of birth (since we had no patient born before December 1901). I think I even have some Scala classes for that, but have to ask whether they can be used.
Anyway, dw is not written in Scala, but still, this can feature can be added as an experiment.
What do you think?
(I've just joined this group, and this is my first post, so I might be missing something, please correct me in this case.)
no subject
no subject
no subject
:) I kind of know that. I have some experience with them. 6 years at Borland, synchronizing resources translations coming from around the world (nobody synchronized clocks on desktops those days), similar stuff at Google; 3.5 years in a company where discovering/deciphering dates from "Explanation of Benefits"... in all these cases it was about real-life time.
no subject
no subject
In this specific case I feel like it won't be. Not in general settings. In general settings, like, suppose we need a duration - suddenly kaboom, we will need int64 if we have both negative and positive timestamps.
But do we have a duration anywhere in the codebase? Just comparing dates would be enough, right? But again, have to make sure that comparison works properly when we compare MIN_INT and MAX_INT. This is not guaranteed.
I don't see where else, beyond comparison and durations, we can have any kind of problems. Theoretically speaking.
no subject
no subject
:) With Perl, anything can happen. Well, my codebase at Borland was in Perl, but... yes. I'd rather agree.
no subject
That said, thanks for posting the feature request, I think it's a good suggestion to make even if implementing might not be straightforward at all. In addition to users wanting to import journal entries from before 1970, there are probably roleplayers who'd like to date their characters' entries in the past.
And as you say, 2038 is approaching, so something's going to have to change in the next (gulp) 14 years.
no subject
First, I presume DW is written in Perl (as it inherits the original LJ code). Perl has a lot of modules for date/time manipulation, though all of them ave caveats and corner cases. It will require a lot of efforts to properly change the data processing.
Second, I presume the dates are stored in a regular database in a format native to this database. If it doesn't support negative date, it would be necessary to provide some workaround (also stored in the database, and so altering the structure - which is a pain for big enough data) and reimplement al the procedures currently fetching this data and processing it (see p.1).
I clearly understand your intentions but if I was a developer I would strongly dodge from implementing this :)
no subject
Definitely depends a lot on the db format. I've started feeling now that keeping dates as long unix millis is a much more flexible approach than any db-specific datetime. Closer to physics, farther from db designers assumptions.
Well, and it's Perl...