| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
turns out the old hafas-rs project that started with trainsear.ch has
since been picked up by some gnome people who use it for
their (creatively named) Railway app. It's a lot more general now,
though the documentation doesn't seem to have improved much 🙃
|
|
|
|
|
| |
these are not present when other hafas backends than the DB one were
used for the trip's checkin.
|
|
|
|
| |
(yuka's version is no longer maintained & broke)
|
|
|
|
|
|
| |
(travelynx sends these as the literal epoch value, which led
to really confusing results, printing exactly the time zone offset
as arrival time)
|
|
|
|
| |
(using yuka's hafas-rs)
|
| |
|
|
|
|
| |
it's not as nice as i'd like, but whatever
|
|
|
|
| |
which … fine, i guess
|
|
|
|
| |
… lots and lots of traits …
|
|
|
|
| |
(added a simple zugportal.de api client, but can't do auto-checkin yet)
|
| |
|
| |
|
|
|
|
|
| |
(also why do people get up from their seats a solid nine minutes before
the train is even scheduled to arrive at all?)
|
|
|
|
|
| |
why use unix time if you can use unix time * 1000 while your margin of
error will never be lower than a full minute?
|
|
|
|
|
|
|
| |
I'm pretty sure something in parsing the times is broken, since this
train is currently /also/ broken I have absolutely no idea what the
correct ones would be and don't have the energy to dig further into
this.
|
| |
|
|
|
|
| |
I have no intention of going to Hamburg today, so I need to check out earlier
|
| |
|
| |
|
| |
|
|
|